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并不能提供注册与路由寻址方式，会影响整个集群对外提供服务，严重违背分布式架构的高可用设计理念。
