高并发消息服务容错与分布式事务优化方案.pdfVIP

1、

可靠消息服务这块，这块东西，大量的基于mysql来了message消息，第一个问题是并

发的问题，如果这个消息发送的特别频繁，每秒钟有几万个消息，mysql绝对就扛不住了，

你要不就是分库分表，用多台数据库服务器来支撑高并发的写入，要么就是使用NoSQL类

的

举个例子，比如可以使用redis、zookeeper、hbase

数据量可能会太大了，并发量很大，消息的增长绝对是大量的，每秒钟几万个消息，一分钟

就上百万消息，10分钟，上千万消息，1小时，上亿，1天，几十亿数据量

定时的清理数据，人家过来只要确认消息成功了，就立马删除，不要保存太多的数据

2、适用场景

大部分的中小型公司，大公司，也可以用，不是那么多的公司都有所谓的高并发，其实主要

还是针对分布式复杂的业务系统，保证分布式事务的最终一致性，那么其实哪怕就直接用我

们的这个方案也是ok的

用到这个方案的只不过是系统的里少量场景的话

3、如果在公司里要大面积使用

现在是直接在代码里面写死了，直接就是回调流量充值服务，其实如果很多其他的服务要接

入你的话，你可能得做一个界面，对每个服务分配一个AppKey，每个服务的AppKey设置一

个回调接口

然后在发送message的时候，标识一下是哪个服务发送过来的

如果要回调服务，那么就根据messa