说说MQ之RocketMQ（一）

RocketMQ 是出自 A 公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好，目前，RocketMQ 的文档仍然不够丰富12，社区仍然无法与 Kafka 比肩，但 A 公司已经推出了基于 RocketMQ 的云产品 3，相信未来 RocketMQ 也会有不错的发展。本文采用 RocketMQ 3.2.6 进行实验，由于 RocketMQ 与 Kafka 很相似，本文很多地方对两者做出了比较。

基本概念

RocketMQ 由于借鉴了 Kafka 的设计，包括组件的命名也很多与 Kafka 相似，下面摘抄一段《RocketMQ 原理简介》中的介绍，可以与 Kafka 的命名比对一下，

• Producer，消息生产者，负责产生消息，一般由业务系统负责产生消息。
• Consumer，消息消费者，负责消费消息，一般是后台系统负责异步消费。
• Push Consumer，Consumer 的一种，应用通常向 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立 刻回调 Listener 接口方法。
• Pull Consumer，Consumer 的一种，应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制。
• Producer Group，一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。
• Consumer Group，一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。
• Broker，消息中转角色，负责存储消息，转发消息，一般也称为 Server。在 JMS 规范中称为 Provider。

《RocketMQ 原理简介》中还介绍了一些其他的概念，例如，广播消费和集群消费，广播消费是 Consumer Group 中对于同一条消息每个 Consumer 都消费，集群消费是 Consumer Group 中对于同一条消息只有一个 Consumer 消费。Kafka 采用的是集群消费，不支持广播消费（好吧，是我没有找到）。再例如，普通顺序消息和严格顺序消息，普通顺序消息在 Broker 重启情况下不会保证消息顺序性；严格顺序消息即使在异常情况下也会保证消息的顺序性。个人理解，所谓普通顺序消息，应该就是 Kafka 中的 Partition 级别有序，严格顺序消息，应该是 Topic 级别有序，但文中也提到，这样的有序级别是要付出代价的，Broker 集群中只要有一台机器不可用，则整个集群都不可用，降低服务可用性。使用这种模式，需要依赖同步双写，主备自动切换，但自动切换功能目前还未实现（我猜，自动切换仅仅是没开源吧）。说白了，严格顺序消息不具备生产可用性，自己玩玩还行，其应用场景主要是数据库 binlog 同步。

关于 RocketMQ 和 Kafka 的对比，可以参考 RocketMQ Wiki 中的文章4，看看就行，不必较真。

关于顺序和分区

顺序性的话题，刚才已经提到了一些，RocketMQ 的实现应该不弱于 Kafka。对于分区，RocketMQ 似乎有意弱化了这个概念，只有在 Producer 中有一个参数 defaultTopicQueueNums ，分区在 RocketMQ 中有时被称为队列。RocketMQ 的普通顺序消息模式，应该就是分区顺序性，这点与 Kafka 一致。

关于高可用

RocketMQ 实现高可用的方式有多种，《RocketMQ 用户指南》文档中提到的有：多主模式、多主多从异步复制模式、多主多从同步复制模式。多主模式下，性能较好，但是在 Broker 宕机的时候，该 Broker 上未消费的交易不可消费；多主多从异步复制模式，与 Kafka 的副本模式比较类似，主 Broker 宕机后，会自动切换到从 Broker，消息的消费不会出现间断；多主多从同步复制模式更进一步，采用同步刷盘的方式，避免了主 Broker 宕机带来的消息丢失，但是，目前不支持自动切换。

虽然 RocketMQ 提供了多种高可用方式，但是目前能生产使用的就只有多主多从异步复制模式，即使在这个模式上，其实现也比 Kafka 要差。因为 RocketMQ 的机制中，主从关系是人为指定的，主 Broker 上承担所有的消息派发，而 Kafka 的主从关系是通过选举的方式选出来的，每个分区的主节点都是不一样的，可以从不同的节点派发消息。Kafka 的模式是分散模式，有利于负载均衡，而且当一个 Broker 宕机的时候，只影响部分 Topic，而 RocketMQ 一旦主 Broker 宕机，会影响所有的 Topic。另外，Kafka 可以支持 Broker 间同步复制（通过设置 Broker 的 acks 参数），这样比的话，RocketMQ 就差太多了。

关于 RocketMQ 的介绍，网上的文章不算太多，也比较杂，《分布式开放消息系统(RocketMQ)的原理与实践》5 6 7这篇原理介绍的不错，推荐。

RocketMQ 的 工具 和编程接口

RocketMQ 的工具

相比较 Kafka 而言，RocketMQ 提供的工具要少一些，如下，

bin/mqadmin
bin/mqbroker
bin/mqbroker.numanode0
bin/mqbroker.numanode1
bin/mqbroker.numanode2
bin/mqbroker.numanode3
bin/mqfiltersrv
bin/mqnamesrv
bin/mqshutdown

除了进程启停之外，常用的运维命令都在 mqadmin 中，详见《RocketMQ 运维指令》文档。我实验中常用的一些命令如下，

sh mqnamesrv &
sh mqbroker -c async-broker-a.properties &
sh mqbroker -c async-broker-a-s.properties &
sh mqadmin topicList -n 192.168.232.23:9876
sh mqadmin topicRoute -n 192.168.232.23:9876 -t TopicTestjjj
sh mqadmin clusterList -n 192.168.232.23:9876
sh mqadmin deleteTopic -c DefaultCluster -n 192.168.232.23:9876 -t TopicTestjjj
sh mqadmin consumerProgress -n 192.168.232.23:9876 -g ConsumerGroupNamecc4
sh mqadmin deleteSubGroup -c DefaultCluster -n 192.168.232.23:9876 -g ConsumerGroupNamecc4
sh mqadmin consumerConnection -n 192.168.232.23:9876 -g ConsumerGroupNamecc4

RocketMQ 使用了自己的 name server 来做调度（Kafka 用了 Zookeeper），使用 sh mqnamesrv 来启动，默认监听端口9876， sh mqnamesrv -m 可以查看所有默认参数，使用  -c xxxx.properties 参数来指定自定义配置。 sh mqbroker 是用于启动 Broker 的命令，参数比较多，详细可以通过  sh mqbroker -m 查看默认参数，配置项细节后文再说。 sh mqadmin 是运维命令入口， topicList 是列出所有 Topic； topicRoute 是列出单个 Topic 的详细信息； clusterList 是列出集群的信息； deleteTopic 是删除 Topic。 consumerProgress 是查看消费者消费进度， deleteSubGroup 是删除消费者的订阅， consumerConnection 是查询消费者订阅的情况。

Broker 的配置是最多的，实验中我修改到的部分如下，其他使用默认，

brokerClusterName=DefaultCluster
brokerIP1=192.168.232.23
brokerName=broker-a
brokerId=0
namesrvAddr=192.168.232.23:9876
listenPort=10911
deleteWhen=04
fileReservedTime=120
storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-a-async
storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-a-async/commitlog
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

配置文件中的多数配置看例子就可以知道意思，挑几个说一下。 brokerName 和  brokerId ， 同名的 Broker，ID 是0的是主节点，其他是从节点； deleteWhen ，删除文件时间点，默认凌晨4点； fileReservedTime ，文件保留时间，设置为120小时； brokerRole ，Broker 的角色，ASYNC_MASTER 是异步复制主节点，SYNC_MASTER 是同步双写主节点，SLAVE 是备节点。

其实，这些工具的写法也基本一致，都是先做一些检查，最后运行 Java 程序，JVM 系统上的应用应该差不多都这样。