生产环境出现网络分区，RocketMQ集群表示毫无压力！！！

之所以需要详细阐述，这里不仅仅涉及具体的工作机制，更是能体现背后的设计理念，请容我慢慢道来。

1、RocketMQ路由注册机制与缺陷

RocketMQ的路由注册机制如下：

• Broker 每30s向 NameServer 发送心跳包，心跳包中包含主题的路由信息（主题的读写队列数、操作权限等），NameServer 会通过 HashMap 更新 Topic 的路由信息，并记录最后一次收到 Broker 的时间戳。
• NameServer 以每10s的频率清除已宕机的 Broker，NameServr 认为 Broker 宕机的依据是如果当前系统时间戳减去最后一次收到 Broker 心跳包的时间戳大于120s。
• 消息生产者以每30s的频率去拉取主题的路由信息，即消息生产者并不会立即感知 Broker 服务器的新增与删除
• broker与nameserver之间的连接断开，对应的borker中的路由信息会从nameserver中立即剔除，但同样需要等客户端主动来更新路由信息才会被感知。

上面的实现方式非常的简单高效，但也存在两个非常明显的缺陷：

• 消息发送者、消息消费者无法及时感知broker服务器的宕机与假死，即无法及时获取最新的路由信息。
• nameserver之间相互不通信，nameserver之间的路由信息会存在不一致形象，但能最终保证一致性。

由于粉丝朋友的关注点在网络分区，网络分区，更加关注的就是nameserver存储的路由信息会不致，接下来重点探讨网络分区。

2、网络分区造成长时间数据不一致

从路由的注册机制来看，各个nameserver之间的路由信息会存在短暂的不一致性，但都能在较短时间内达到一致，在路由寻址场景中是可以接受的，但如果出现网络分区，则数据无法达到一致，示意图如下：例如如果两个网段出现异常，阐述所谓的网络分区，整个集群被划分在两个分区中，如果出现网段1与网段2不能访问，但网段-3可以访问网1、2。

网段1与网段2之间无法互通，会导致broker-a中的topic路由信息不会存储到nameserver-b，broker-b、broker-c中topic的路由信息同样不会存储到nameserver-a中。

2.1对消息发送到影响

在rocketmq中消息发送者同一时间只会连接一台nameserver，消息发送方(Producer-1)连接到是nameserver-a,从中查出4个队列，那该消息发送者发送到消息都回发送到到broker-a；

如果另一消息发送者（Producer-2）连接到是nameserver-b，则发送到消息会分布到broker-b,broker-c，如果Producer-1需要发送消息是2百万条，而Producer-2只发送10W条消息。

网络分区并不会造成消息发送失败，而是可能引发消息分布不均衡。

2.2 对消息消费的影响

在rocketmq中，消息队列的负载机制有很多，但基本都是得出topic的队列个数、当前活跃的消费者个数，然后根据负载算法(例如平均分配)。

如果消费者连接的都是同一个机房的nameserver，例如全部是网段-1中的nameserver-a，那broker-b、broker-c中的消息则无法被消费。因为路由信息中不包含broker-b、broker-c中的队列。

如果部分消费者连接nameserver-a、部分连接nameserver-b,则最终的效果是消费者也会产生分区效果：例如c1连接nameserver-a、c2、c3连接nameserver-b，则c1会消费broker-a中的消息，而c2,c3共同消费broker-b,broker-c的消息。

从这里可以看出，网络分区对消费端还是存在较大影响，但容易感知，并且在网络恢复后，消息并不会丢失。

3、架构思考

大家一定会问，RocketMQ的路由注册存在明显缺陷，为什么作为一个Apache顶级项目竟然会存在这样缺陷，是水平不够？

当然不是，这恰恰是一种架构权衡。

RocketMQ的Nameserver其设计理念是追求简单、高性能，关键是经过上面的分析，就算是出现不一致，所带来的并不是灾难级。

但换过来，如果采用诸如zookeeper这种追求强一致性框架，如果出现网络分区，严重的时候zookeeper并不能提供注册与路由寻址方式，会影响整个集群对外提供服务，严重违背分布式架构的高可用设计理念。

推荐阅读：

欢迎关注微信公众号：互联网全栈架构，收取更多有价值的信息。