分析rocketMq

代码地址： git@github.com:tuyf/kafka.git

 

主要四个实例：

 

第一个： Java访问rocketMq

见类 Producer 和 Consumer

 

第二个： Spring整合rocketMq

见类SpringProducer和SpringConsumer

 

第三个： 基于rocketMq的消息顺序处理

在order package下的代码，重点介绍它的顺序消费。

rocketMq中的顺序消费，一般指的是局部顺序，不是全局顺序。

默认的情况下，消息生产者采用轮询的方式来选择具体的队列 发送消息， 要想满足顺序消费的要求，必须保证 按照业务上的顺序 把消息发送到Broker上的同一个队列中； 因为不保证其他生产者 也会发消息到该队列，所以还需要消费者 对接收到的消息 做一些过滤。

顺序消费存在的问题：

1 无法利用集群的FailOver特性， 如果某个master宕机，无法重试。

2 顺序消费的消费并行度 依赖队列的数量。

3 遇到消费失败的消息不能跳过，只能暂停当前队列的消费。

4 实现顺序消息时，把选择发送的路由 交给业务侧实现， 可能会由于哈希不均 导致消息过多 使某些队列中数据多，造成消息堆积。

实现顺序消费， 主要是在 消费者consumer端，注册的消息监听器是 MessageListenerOrderly

 

 

第四个： 基于rocketMq的分布式事务      

这个与前面的基于 activeMq的分布式事务 对比记忆。(activeMq的分布式事务 是把分布式事务 拆成了 两个本地事务来处理；此处的话，是把分布式事务 拆成了一个消息事务(系统A的本地事务+发消息) + 系统B的本地事务)， 可以少创建两张event表。

 

RocketMQ 4.3 中的事务消息在设计上 借鉴了 2PC的理论，交互图如下：

 

 

 

 

消息重试：

生产者端重试：

 

消费者端重试：

 

消息重复：

MQ产品 投递消息面临三种模式的选择：

至少一次

最多一次

只有一次

遗留问题：rocketMq的集群模式下，再均衡的具体实现；

类MessageListenerOrderly 底层是 如何实现顺序消费的