linuxheik

说说 MQ 之 RocketMQ，顺序消费和无序消费

RocketMQ 是出自 A 公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好，目前，RocketMQ 的文档仍然不够丰富 1 2，社区仍然无法与 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 系统上的应用应该差不多都这样。

RocketMQ 的 Java API

RocketMQ 是用 Java 语言开发的，因此，其 Java API 相对是比较丰富的，当然也有部分原因是 RocketMQ 本身提供的功能就比较多。RocketMQ API 提供的功能包括，

广播消费，这个在之前已经提到过；
消息过滤，支持简单的 Message Tag 过滤，也支持按 Message Header、body 过滤；
顺序消费和乱序消费，之前也提到过，这里的顺序消费应该指的是普通顺序性，这一点与 Kafka 相同；
Pull 模式消费，这个是相对 Push 模式来说的，Kafka 就是 Pull 模式消费；
事务消息，这个好像没有开源，但是 example 代码中有示例，总之，不推荐用；
Tag，RocketMQ 在 Topic 下面又分了一层 Tag，用于表示消息类别，可以用来过滤，但是顺序性还是以 Topic 来看；

单看功能的话，即使不算事务消息，也不算 Tag，RocketMQ 也远超 Kafka，Kafka 应该只实现了 Pull 模式消费 + 顺序消费这2个功能。RocketMQ 的代码示例在 rocketmq-example 中，注意，代码是不能直接运行的，因为所有的代码都少了设置 name server 的部分，需要自己手动加上，例如，producer.setNamesrvAddr("192.168.232.23:9876");。

先来看一下生产者的 API，比较简单，只有一种，如下，

import com.alibaba.rocketmq.client.exception.MQClientException;

import com.alibaba.rocketmq.client.producer.DefaultMQProducer;

import com.alibaba.rocketmq.client.producer.MessageQueueSelector;

import com.alibaba.rocketmq.client.producer.SendResult;

import com.alibaba.rocketmq.common.message.Message;

import com.alibaba.rocketmq.common.message.MessageQueue;

import java.util.List;

public class Producer {

public static void main(String[] args) throws MQClientException, InterruptedException {

DefaultMQProducer producer = new DefaultMQProducer( "ProducerGroupName");

producer.setNamesrvAddr( "192.168.232.23:9876");

producer.start();

for ( int i = 0; i < 10; i++)

try {

{

Message msg = new Message( "TopicTest1", // topic

"TagA", // tag

"OrderID188", // key

( "RocketMQ "+String.format( "%05d", i)).getBytes()); // body

SendResult sendResult = producer.send(msg, new MessageQueueSelector() {

@Override

public MessageQueue select(List mqs, Message msg, Object arg) {

Integer id = (Integer) arg;

int index = id % mqs.size();

return mqs.get(index);

}

}, i));

System.out.println(String.format( "%05d", i)+sendResult);

}

catch (Exception e) {

e.printStackTrace();

}

producer.shutdown();

}

可以发现，相比 Kafka 的 API，只多了 Tag，但实际上行为有很大不同。Kafka 的生产者客户端，有同步和异步两种模式，但都是阻塞模式，send 方法返回发送状态的 Future，可以通过 Future 的 get 方法阻塞获得发送状态。而 RocketMQ 采用的是同步非阻塞模式，发送之后立刻返回发送状态（而不是 Future）。正常情况下，两者使用上差别不大，但是在高可用场景中发生主备切换的时候，Kafka 的同步可以等待切换完成并重连，最后返回；而 RocketMQ 只能立刻报错，由生产者选择是否重发。所以，在生产者的 API 上，其实 Kafka 是要强一些的。

另外，RocketMQ 可以通过指定 MessageQueueSelector 类的实现来指定将消息发送到哪个分区去，Kafka 是通过指定生产者的 partitioner.class 参数来实现的，灵活性上 RocketMQ 略胜一筹。

再来看消费者的API，由于 RocketMQ 的功能比较多，我们先看 Pull 模式消费的API，如下，

import java.util.HashMap;

import java.util.Map;

import java.util.Set;

import com.alibaba.rocketmq.client.consumer.DefaultMQPullConsumer;

import com.alibaba.rocketmq.client.consumer.PullResult;

import com.alibaba.rocketmq.client.consumer.store.OffsetStore;

import com.alibaba.rocketmq.client.consumer.store.RemoteBrokerOffsetStore;

import com.alibaba.rocketmq.client.exception.MQClientException;

import com.alibaba.rocketmq.common.message.MessageExt;

import com.alibaba.rocketmq.common.message.MessageQueue;

public class PullConsumer {

private static final Map offseTable = new HashMap();

public static void main(String[] args) throws MQClientException {

DefaultMQPullConsumer consumer = new DefaultMQPullConsumer( "please_rename_unique_group_name_5");

consumer.setNamesrvAddr( "192.168.232.23:9876");

consumer.start();

Set mqs = consumer.fetchSubscribeMessageQueues( "TopicTest1");

for (MessageQueue mq : mqs) {

System.out.println( "Consume from the queue: " + mq);

SINGLE_MQ: while ( true) {

try {

long offset = consumer.fetchConsumeOffset(mq, true);

PullResult pullResult =

consumer.pullBlockIfNotFound(mq, null, getMessageQueueOffset(mq), 32);

if ( null != pullResult.getMsgFoundList()) {

for (MessageExt messageExt : pullResult.getMsgFoundList()) {

System.out.print( new String(messageExt.getBody()));

System.out.print(pullResult);

System.out.println(messageExt);

}

putMessageQueueOffset(mq, pullResult.getNextBeginOffset());

switch (pullResult.getPullStatus()) {

case FOUND:

// TODO

break;

case NO_MATCHED_MSG:

break;

case NO_NEW_MSG:

break SINGLE_MQ;

case OFFSET_ILLEGAL:

break;

default:

break;

}

catch (Exception e) {

e.printStackTrace();

}

consumer.shutdown();

}

private static void putMessageQueueOffset(MessageQueue mq, long offset) {

offseTable.put(mq, offset);

}

private static long getMessageQueueOffset(MessageQueue mq) {

Long offset = offseTable.get(mq);

if (offset != null)

return offset;

return 0;

}

这部分的 API 其实是和 Kafka 很相似的，唯一不同的是，RocketMQ 需要手工管理 offset 和指定分区，而 Kafka 可以自动管理（当然也可以手动管理），并且不需要指定分区（分区是在 Kafka 订阅的时候指定的）。例子中，RocketMQ 使用 HashMap 自行管理，也可以用 OffsetStore 接口，提供了两种管理方式，本地文件和远程 Broker。这部分感觉两者差不多。

下面再看看 Push 模式顺序消费，代码如下，

import java.util.List;

import java.util.concurrent.atomic.AtomicLong;

import com.alibaba.rocketmq.client.consumer.DefaultMQPushConsumer;

import com.alibaba.rocketmq.client.consumer.listener.ConsumeOrderlyContext;

import com.alibaba.rocketmq.client.consumer.listener.ConsumeOrderlyStatus;

import com.alibaba.rocketmq.client.consumer.listener.MessageListenerOrderly;

import com.alibaba.rocketmq.client.exception.MQClientException;

import com.alibaba.rocketmq.common.consumer.ConsumeFromWhere;

import com.alibaba.rocketmq.common.message.MessageExt;

public class Consumer {

public static void main(String[] args) throws MQClientException {

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer( "please_rename_unique_group_name_3");

consumer.setNamesrvAddr( "192.168.232.23:9876");

consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);

consumer.subscribe( "TopicTest1", "TagA || TagC || TagD");

consumer.registerMessageListener( new MessageListenerOrderly() {

AtomicLong consumeTimes = new AtomicLong( 0);

@Override

public ConsumeOrderlyStatus consumeMessage(List msgs, ConsumeOrderlyContext context) {

context.setAutoCommit( false);

System.out.println(Thread.currentThread().getName() + " Receive New Messages: " + msgs);

this.consumeTimes.incrementAndGet();

if (( this.consumeTimes. get() % 2) == 0) {

return ConsumeOrderlyStatus.SUCCESS;

}

else if (( this.consumeTimes. get() % 3) == 0) {

return ConsumeOrderlyStatus.ROLLBACK;

}

else if (( this.consumeTimes. get() % 4) == 0) {

return ConsumeOrderlyStatus.COMMIT;

}

else if (( this.consumeTimes. get() % 5) == 0) {

context.setSuspendCurrentQueueTimeMillis( 3000);

return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;

}

return ConsumeOrderlyStatus.SUCCESS;

}

});

consumer.start();

System.out.println( "Consumer Started.");

}

虽然提供了 Push 模式，RocketMQ 内部实际上还是 Pull 模式的 MQ，Push 模式的实现应该采用的是长轮询，这点与 Kafka 一样。使用该方式有几个注意的地方，

接收消息的监听类要使用 MessageListenerOrderly；
ConsumeFromWhere 有几个参数，表示从头开始消费，从尾开始消费，还是从某个 TimeStamp 开始消费；
可以控制 offset 的提交，应该就是 context.setAutoCommit(false); 的作用；

控制 offset 提交这个特性非常有用，某种程度上扩展一下，就可以当做事务来用了，看代码 ConsumeMessageOrderlyService 的实现，其实并没有那么复杂，在不启用 AutoCommit 的时候，只有返回 COMMIT 才 commit offset；启用 AutoCommit 的时候，返回 COMMIT、ROLLBACK（这个比较扯）、SUCCESS 的时候，都 commit offset。

后来发现，commit offset 功能在 Kafka 里面也有提供，使用新的 API，调用 consumer.commitSync。

再看一个 Push 模式乱序消费 + 消息过滤的例子，消费者的代码如下，

import java.util.List;

import com.alibaba.rocketmq.client.consumer.DefaultMQPushConsumer;

import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;

import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;

import com.alibaba.rocketmq.client.consumer.listener.MessageListenerConcurrently;

import com.alibaba.rocketmq.client.exception.MQClientException;

import com.alibaba.rocketmq.common.message.MessageExt;

public class Consumer {

public static void main(String[] args) throws InterruptedException, MQClientException {

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer( "ConsumerGroupNamecc4");

consumer.setNamesrvAddr( "192.168.232.23:9876");

consumer.subscribe( "TopicTest1", MessageFilterImpl. class.getCanonicalName());

consumer.registerMessageListener( new MessageListenerConcurrently() {

@Override

public ConsumeConcurrentlyStatus consumeMessage(List msgs,

ConsumeConcurrentlyContext context) {

System.out.println(Thread.currentThread().getName() + " Receive New Messages: " + msgs);

return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

}

});

consumer.start();

System.out.println( "Consumer Started.");

}

这个例子与之前顺序消费不同的地方在于，

接收消息的监听类使用的是 MessageListenerConcurrently；
回调方法中，使用的是自动 offset commit；
订阅的时候增加了消息过滤类 MessageFilterImpl；

消息过滤类 MessageFilterImpl 的代码如下，

import com.alibaba.rocketmq.common.filter.MessageFilter;

import com.alibaba.rocketmq.common.message.MessageExt;

public class MessageFilterImpl implements MessageFilter {

@Override

public boolean match(MessageExt msg) {

String property = msg.getUserProperty( "SequenceId");

if (property != null) {

int id = Integer.parseInt(property);

if ((id % 3) == 0 && (id > 10)) {

return true;

}

return false;

}

RocketMQ 执行过滤是在 Broker 端，Broker 所在的机器会启动多个 FilterServer 过滤进程；Consumer 启动后，会向 FilterServer 上传一个过滤的 Java 类；Consumer 从 FilterServer 拉消息，FilterServer 将请求转发给 Broker，FilterServer 从 Broker 收到消息后，按照 Consumer 上传的 Java 过滤程序做过滤，过滤完成后返回给 Consumer。这种过滤方法可以节省网络流量，但是增加了 Broker 的负担。可惜我没有实验出来使用过滤的效果，即使是用 github wiki 上的例子8也没成功，不纠结了。RocketMQ 的按 Tag 过滤的功能也是在 Broker 上做的过滤，能用，是个很方便的功能。

还有一种广播消费模式，比较简单，可以去看代码，不再列出。

总之，RocketMQ 提供的功能比较多，比 Kafka 多很多易用的 API。

RocketMQ 的主备模式

按之前所说，只有 RocketMQ 的多主多从异步复制是可以生产使用的，因此只在这个场景下测试。另外，消息采用 Push 顺序模式消费。

假设集群采用2主2备的模式，需要启动4个 Broker，配置文件如下，

brokerName=broker-a

brokerId= 0

listenPort= 10911

storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-a-async

storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-a-async/commitlog

brokerRole=ASYNC_MASTER

brokerName=broker-a

brokerId= 1

listenPort= 10921

storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-a-async-slave

storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-a-async-slave/commitlog

brokerRole=SLAVE

brokerName=broker-b

brokerId= 0

listenPort= 20911

storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-b-async

storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-b-async/commitlog

brokerRole=ASYNC_MASTER

brokerName=broker-b

brokerId= 1

listenPort= 20921

storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-b-async-slave

storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-b-async-slave/commitlog

brokerRole=SLAVE

另外，每个机构共通的配置项如下，

brokerClusterName=DefaultCluster

brokerIP1= 192.168. 232.23

namesrvAddr= 192.168. 232.23: 9876

deleteWhen= 04

fileReservedTime= 120

flushDiskType=ASYNC_FLUSH

其他设置均采用默认。启动 NameServer 和所有 Broker，并试运行一下 Producer，然后看一下 TestTopic1 当前的情况，

$ sh mqadmin topicRoute -n 192.168. 232.23 : 9876 -t TopicTest1

{

"brokerDatas" :[

{

"brokerAddrs" :{ 0 :"192.168.232.23:20911", 1 :"192.168.232.23:20921"

"brokerName" :"broker-b"

{

"brokerAddrs" :{ 0 :"192.168.232.23:10911", 1 :"192.168.232.23:10921"

"brokerName" :"broker-a"

}

"filterServerTable" :{},

"queueDatas" :[

{

"brokerName" :"broker-a",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

{

"brokerName" :"broker-b",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

}

]

}

可见，TestTopic1 在2个 Broker 上，且每个 Broker 备机也在运行。下面开始主备切换的实验，分别启动 Consumer 和 Producer 进程，消息采用 Pull 顺序模式消费。在消息发送接收过程中，使用 kill -9 停掉 broker-a 的主进程，模拟突然宕机。此时，TestTopic1 的状态如下，

$ sh mqadmin topicRoute -n 192.168. 232.23 : 9876 -t TopicTest1

{

"brokerDatas" :[

{

"brokerAddrs" :{ 0 :"192.168.232.23:20911", 1 :"192.168.232.23:20921"

"brokerName" :"broker-b"

{

"brokerAddrs" :{ 1 :"192.168.232.23:10921"

"brokerName" :"broker-a"

}

"filterServerTable" :{},

"queueDatas" :[

{

"brokerName" :"broker-a",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

{

"brokerName" :"broker-b",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

}

]

}

broker-a 的节点已经减少为只有1个从节点。然后启动broker-a 的主节点，模拟恢复，再看一下 TestTopic1 的状态，

$ sh mqadmin topicRoute -n 192.168. 232.23 : 9876 -t TopicTest1

{

"brokerDatas" :[

{

"brokerAddrs" :{ 0 :"192.168.232.23:20911", 1 :"192.168.232.23:20921"

"brokerName" :"broker-b"

{

"brokerAddrs" :{ 0 :"192.168.232.23:10911", 1 :"192.168.232.23:10921"

"brokerName" :"broker-a"

}

"filterServerTable" :{},

"queueDatas" :[

{

"brokerName" :"broker-a",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

{

"brokerName" :"broker-b",

"perm" : 6,

"readQueueNums" : 4,

"topicSynFlag" : 0,

"writeQueueNums" : 4

}

]

}

此时，RocketMQ 已经恢复。

再来看看 Producer 和 Consumer 的日志，先看 Producer 的，如下，

100

101

102

103

104

105

106

107

108

109

......

00578SendResult [ sendStatus=SEND_OK, msgId=C0A8E81700002A9F0000000000126F08, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-a, queueId= 2], queueOffset= 141]

00579SendResult [ sendStatus=SEND_OK, msgId=C0A8E81700002A9F0000000000126F9F, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-a, queueId= 3], queueOffset= 141]

00580SendResult [ sendStatus=SEND_OK, msgId=C0A8E817000051AF0000000000078D47, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-b, queueId= 0], queueOffset= 700]

00581SendResult [ sendStatus=SEND_OK, msgId=C0A8E817000051AF0000000000078DDE, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-b, queueId= 1], queueOffset= 700]

00582SendResult [ sendStatus=SEND_OK, msgId=C0A8E817000051AF0000000000078E75, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-b, queueId= 2], queueOffset= 699]

00583SendResult [ sendStatus=SEND_OK, msgId=C0A8E817000051AF0000000000078F0C, messageQueue=MessageQueue [ topic=TopicTest1, brokerName=broker-b, queueId= 3], queueOffset= 699]

com.alibaba.rocketmq.remoting.exception.RemotingConnectException: connect to < 192.168. 232.23: 10911> failed

at com.alibaba.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java: 641)

at com.alibaba.rocketmq.client.impl.MQClientAPIImpl.sendMessageSync(MQClientAPIImpl.java: 306)

at com.alibaba.rocketmq.client.impl.MQClientAPIImpl.sendMessage(MQClientAPIImpl.java: 289)

at com.alibaba.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendKernelImpl(DefaultMQProducerImpl.java: 679)

at com.alibaba.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendSelectImpl(DefaultMQProducerImpl.java: 867)

at com.alibaba.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java: 842)

at com.alibaba.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java: 836)

at com.alibaba.rocketmq.client.producer.DefaultMQProducer.send(DefaultMQProducer.java: 164)

at com.comstar.demo.rocketmq.simple.Producer.main(Producer.java: 61)