可以看到，Consumer 在 broker-a 宕机时间的附近，也出现了异常，connect to <192.168.232.23:10911> failed。虽然还能保持分区上的顺序性，但是已经某种程度上出现了一些紊乱，例如，将我在实验之前的数据给取了出来（Hello MetaQ的消息）。可是，我在实验前，明明做过删除这个 Topic 的动作，看来 RocketMQ 所谓的删除，并未删除 Topic 的数据。之后，broker-a 主机重启之后，又恢复正常。

RocketMQ Pull模式消费需要手动管理 offset 和指定分区，这个在调用的时候不觉得，实际运行的时候才会发现每次总是消费一个分区，消费完之后，才开始消费下一个分区，而下一个分区可能已经堆积了很多消息了，手动做消息分配又比较费事。或许，Push 顺序模式消费才是更好的选择。

另外还有几个比较异常的情况，实验中有几次出现了 CODE: 17 DESC: topic[TopicTest1] not exist, apply first please! 这样的错误，实际上，这时候我只是关掉了 Producer；还有，sh mqadmin updateTopic –n 192.168.232.23:9876 –c DefaultCluster –t TopicTest1 明明文档中说可以用来新增 Topic，而实际上不行。

补充一下：之后，我又使用 Push 顺序模式消费重做了上述实验，结论差不多。只是因为有多线程的原因，日志看起来偶尔有错位，这个问题不大，可以解决。而且，在关闭重启 Broker 的附近，往往伴随着多次的消息重发，不过，RocketMQ 也不保证消息只收到一次就是了。消息重复的问题，Kafka 要比 RocketMQ 显得不那么严重一些。Push 顺序模式消费不需要指定 offset，不需要指定分区，第二次启动可以自动从前一次的 offset 后开始消费。功能上这个与 Kafka 的 Consumer 更类似，虽然 RocketMQ 采用的是异步模式。

RocketMQ 最佳实践

实际上，RocketMQ 自己就有一份《RocketMQ 最佳实践》的文档，里面提到了一些系统设计的问题，例如消费者要幂等，一个应用对应一个 Topic，如此等等。这些经验不仅仅是对 RocketMQ 有用，对 Kafka 也颇有借鉴意义。

后记

这里谈谈我对选择 RocketMQ 还是 Kafka 的个人建议。以上已经做了多处 RocketMQ 和 Kafka 的对比，我个人觉得，Kafka 是一个不断发展中的系统，开源社区比 RocketMQ 要大，也要更活跃一些；另外，Kafka 最新版本已经有了同步复制，消息可靠性更有保障；还有，Kafka 的分区机制，几乎实现了自动负载均衡，这绝对是个杀手级特性；RocketMQ 虽然提供了很多易用的功能，远超出 Kafka，但这些功能并不一定都能用得上，而且多数可以绕过。相比之下，Kafka 的基本功能更加吸引我，再处理故障恢复的时候，细节上要胜过 RocketMQ。当然，如果是 A 公司内部，或者所在公司使用了 A 公司的云产品，那么 RocketMQ 的企业级特性更多一些，或许我会选择 RocketMQ。