NameServer

1. Broker 在启动时向所有 NameServer 注册
2. 消息生产者在发送消息之前先从 NameServer 获取 Broker 服务器的地址列表，然后根据负载均衡算法从列表中选择一台 Broker 发送消息
3. 与每台 Broker 服务器保持长连接，并间隔 10s 检测 Broker 是否存活，如果检测到宕机，则从路由表删除，但是路由信息不会马上通知生产者（为了降低 NameServer 复杂性），因此需要在消息发送端提供容错机制来保证消息发送的高可用性
4. NameServer 本身的高可用可通过部署多台 NameServer 实现，每台 NameServer 都会有集群中所有 Broker 的消息，但彼此之前互不通信，虽然可能存在某一时刻多台 NameServer 服务器之间的数据不完全同步，但对消息发送不会造成重大影响，最多短暂造成消息发送不均衡

消息高可用设计

1. topic 信息是存放在消费者方，定时更新
2. 故障规避机制
3. 发送端在自动发现主题的路由信息后，RocketMQ 默认采用轮训算法进行路由的负载均衡。也支持自定义的队列负载均衡算法，但要注意使用自定义的负载均衡算法后，RocketMQ 的重试机制将失效。
   1. RocketMQ 在任务发送失败后默认会重试两次
   2. 当消息第一次发送失败时，如果下一次消息还是刚刚发送失败的 Broker 上，大概率还是会失败，所以在重试时会尽量避开刚刚接收失败的 Broker

发送消息

读写队列

• writeQueue的数量高于readQueue, 就说明有些queue只有写没有读，也就是说会有一部分消息永远都不会消费掉。
  readQueue多于writeQueue的话，就说明有一部分consumer处在空跑的状态。

分为读写队列的目的是扩容缩容更平滑：

• 扩容：先增加 readQueue 数量，这时候 consumer 已经能关联到 queue 上，然后再修改 writeQueue