【转】分析redis消息队列和kafka来解决分布式事务场景

转自 http://blog.csdn.net/fuck__you_/article/details/51527634

 

1、系统A（扣减托盘）【消息生产者】

2、系统B（扣减押金）【消息消费者】

业务描述：

两套系统，A中扣减托盘，B中对应的要扣减押金；A中托盘归还，B中押金返还

 

利用消息队列来解决分布式事务过程：

发送方【生产者】：（不关心接收方状态，只需要确定本地OK，消息推送即可）

1、发送的消息首先需要入库（1⃣表结构：【消息ID，内容，相关事务的ID】）

2、执行本地逻辑操作并commit，发送消息（增加延迟处理，超时未发送成功的—>入库（新的异常消息表），开启新线程继续发送，成功则删除异常消息表信息）

到此为止发送成功

接收方【消费者】：（也不关心发送方状态，只需要接收消息，执行本地操作即可）

1、接收的消息也先入库（1⃣表结构同上）

2、开启新线程处理消息，确保消息一定能执行成功

线程均使用ThreadPoolExecutor线程池

 

1⃣处的好处：

1、消息内容本地持久化，如果真的出现什么问题，便于双方排查问题

2、针对接收方来说，可防止消息的重复发送情况

 

当然这个过程需要确保消息中间件功能完全正常，就算宕机也没有任何影响

本地的逻辑操作和发送消息都可以有超时的判定，但是消息的出队列呢？

 

下面说下Redis消息队列弊端：

消息从queue里面出来，还未到达消费者前网络中断或者各种原因导致消息丢失，而接受者并不知道有此消息最终导致分布式事务不一致的情况，并且该情况的反应时间有可能是几个月后或者更长时间，排查问题也很麻烦

引入消息队列kafka的优势：

kafka本身的消息支持持久化，消息本身以快照的形式保存在磁盘中（并非redis是在内存中），再加上kafka消息队列的特性—>（并非真正意义上的出队列，而是有类似指针只是指向消息的消费情况，即永远指向下一个待消费信息，消息还是在队列中存在，而客户端可以手动控制消息是否被成功消费），这点已经足以可以用kafka来取代原生的redis消息队列，在加上kafka与zookeeper无缝集成，可以在zookeeper中可以很好的监控kafka的brokers（存放消息的仓库）、topics（消息的主题）、partitions（仓库里面的分区）以及指针的offset（偏移量，即消息的消费情况）

最后kafka的吞吐量和集群方式都比redis更优秀（其他的消息队列大家也都可以了解了解）

 

动手玩玩去！~

 

根据下面的文章有感而发：（里面这货是大牛）

http://www.cnblogs.com/LBSer/p/4715395.html