RocketMQ调研

WHY RocketMQ?

Messaging Product	Client SDK	Protocol and Specification	Ordered Message	Scheduled Message	Batched Message	BroadCast Message	Message Filter	Server Triggered Redelivery	Message Storage	Message Retroactive	Message Priority	High Availability and Failover	Message Track	Configuration	Management and Operation Tools
ActiveMQ	Java, .NET, C++ etc.	Push model, support OpenWire, STOMP, AMQP, MQTT, JMS	Exclusive Consumer or Exclusive Queues can ensure ordering	Supported	Not Supported	Supported	Supported	Not Supported	Supports very fast persistence using JDBC along with a high performance journal，such as levelDB, kahaDB	Supported	Supported	Supported, depending on storage,if using kahadb it requires a ZooKeeper server	Not Supported	The default configuration is low level, user need to optimize the configuration parameters	Supported
Kafka	Java, Scala etc.	Pull model, support TCP	Ensure ordering of messages within a partition	Not Supported	Supported, with async producer	Not Supported	Supported, you can use Kafka Streams to filter messages	Not Supported	High performance file storage	Supported offset indicate	Not Supported	Supported, requires a ZooKeeper server	Not Supported	Kafka uses key-value pairs format for configuration. These values can be supplied either from a file or programmatically.	Supported, use terminal command to expose core metrics
RocketMQ	Java, C++, Go	Pull model, support TCP, JMS, OpenMessaging	Ensure strict ordering of messages,and can scale out gracefully	Supported	Supported, with sync mode to avoid message loss	Supported	Supported, property filter expressions based on SQL92	Supported	High performance and low latency file storage	Supported timestamp and offset two indicates	Not Supported	Supported, Master-Slave model, without another kit	Supported	Work out of box,user only need to pay attention to a few configurations	Supported, rich web and terminal command to expose core metrics

架构，主要流程和概念模型：

 

 

 

 

 

 

. 硬件监控和报警
Prometheus & Grafana

. 业务监控的web平台以及部署。
git: https://github.com/apache/rocketmq-externals

 

 

. 出现故障，rocketmq自带补消息的支持。 第一次消费失败进入重试topic:
重试topic: %RETRY%{TOPICNAME} ，重试16次，还失败的话，进入死信topic. 另外，这个重试topic被消费者自动订阅。 不需要手工处理。
死信topic: %DLQ%{TOPICNAME} ，mq认为不是一个正常场景了，需要手工介入处理。

 

 

 

 

 

 

. java的sample代码：
https://github.com/apache/rocketmq-spring

. rocket管理界面上可以根据自定义的key来查消息，tag可以帮助consumer来过滤消息，下面代码示例是示范如何指定一个消息的tag和key：
代码如下：

 

 

 

 可以看到指定的tag和key:

 

 

. 业务监控的web平台以及部署。
git: https://github.com/apache/rocketmq-externals

. 消息可靠性，rocketmq如何保证消息不丢失：

 

 

 

 

. 容灾备份切换
rocketmq在发送消息时，由于nameserver检测broker是否还存活是有延迟的，在选择消息队列时难免会遇到已经宕机的broker， 又或者因为网络原因发送失败的，因此rocketmq采取了一些高可用设计的方案，主要通过两个手段：重试与Broker规避。

rocketmq发送消息时，选择队列有两种方式: 通过sendLatencyFaultEnable的值来控制，默认值为false，不启动broker故障延迟机制，值为true时启用broker故障延迟机制。

另外，基于 DLedger， 可以构建自动容灾切换的 RocketMQ 集群。 每个 RocketMQ-on-DLedger Group 至少准备三台机器，RocketMQ-on-DLedger Group 也可以以 2 节点方式部署，但其会丧失容灾切换能力（2n + 1 原则，至少需要3个节点才能容忍其中 1 个宕机）。

. 最后没有选择rocketmq的原因

1. 数据安全方面，kafka自带的可以支持SASL+ACL, 以及SSL加密。 而rocketmq官方文档我没找到这方面的描述，可能要翻源代码。
2. 可靠性方面， rocketmq每组都至少有两台机器，才能保证服务正常提供。 多组情况下，最少（2n + 1），资源上对比kafka可能有点浪费。而且实际是否如此，还得花一两个周的时间去测试。 对比kafka方面，Tim已经有过实际使用经验。不用担心极端情况下的故障如何处理。
3. 数据中台已经使用了kafka作为收集数据的中间件，如果选择kafka作为消息中间件，可以省掉很多运维的复杂度。
4. rocketmq对比kafka个人选择的理由是因为有消息查询和跟踪功能。而kafka这方面已经看到有相关的框架可以用，比如Spring Cloud Stream 2.0。 所以这个方面也不再成为kafka的弱点了。而且，有了框架可以封装的话。将来即使kafka不适用之后，再做其他中间件的切换，也会比较顺畅。
5. 网传的kafka超过64个Topic之后性能下降，咨询了tim和另一个公司的朋友，都没有遇到类似情况，200多个topic无明显延迟。