RocketMq

1. 延迟消息原理

    broker收到消息，如果是延迟消息，就把消息集中投递到SCHEDULE_TOPIC_XXXX和对应的Queue（queueId和延迟lever匹配），在消息体中设置（真正的topic和queue），broker会有18个task，每个task绑定一个queue，消息到期后，会将消息投递到真正的topic

 

2. 重试队列原理

   https://wuchanming.gitbooks.io/rocketmq/content/rocketmq-ding-shi-xiao-xi-he-zhong-shi-xiao-xi-ff08-shi-er-ff09.html

 

   假定消费的topic名字 “pay_order”  消费组为 “marketing_platform”

   2.1 每个consumer都会额外监听 “%RETRY%CONSUMER_GROUP” 这个topic（所以推荐任意consumer都使用不同的消费组），即 “%RETRY%marketing_platform”

   2.2 消费失败，会将消息发送给broker，broker会把消息放入“SCHEDULE_TOPIC_XXXX”，定时任务扫描发现满足条件，会将消息投递到 “%RETRY%marketing_platform”

   2.3 consumer会拉取到消息，重新消费

   2.4 若超过最大重试次数，broker会把消息投递到死信队列 %DLQ%marketing_platform

 

3. RocketMq VS Kafka

https://baijiahao.baidu.com/s?id=1685027948427296244&wfr=spider&for=pc

Kafka 在性能上综合表现确实要比 RocketMQ 更加的优秀，但在消息选型过程中，我们不仅仅要参考其性能，还有从功能性上来考虑，例如 RocketMQ 提供了丰富的消息检索功能、事务消息、消息消费重试、定时消息等。

笔者个人认为通常在大数据、流式处理场景基本选用 Kafka，业务处理相关选择 RocketMQ。