面试题：消息队列之RocketMQ高可用性设计基础

Question

请简述RocketMQ实现高可用性的主要架构设计，比如NameServer、Broker在其中扮演的角色及如何协同保证可用性。

Answer 1

NameServer 角色及作用

1. 服务发现：NameServer 作为轻量级的服务发现与路由中心，Broker 在启动时会向所有存活的 NameServer 注册自身信息，包括 IP、端口、Topic 配置等。生产者和消费者启动时，从 NameServer 获取 Topic 路由信息，这样使得 Broker 的位置信息对于客户端透明，降低了耦合度。
2. 无状态：NameServer 是无状态的，这意味着每个 NameServer 节点之间相互独立，不进行数据同步。当某个 NameServer 节点出现故障时，不会影响其他节点的正常运行，并且 Broker 和客户端可以通过重试连接到其他 NameServer 节点获取路由信息，保证了系统的可用性。

Broker 角色及作用

1. 主从架构：Broker 采用主从架构来保证高可用性。每个 Master Broker 可以有多个 Slave Broker，Master 负责处理读写请求，Slave 则从 Master 同步数据。当 Master 出现故障时，系统可以通过手动或自动切换机制，将 Slave 提升为 Master，继续提供服务。
2. 数据同步：Master 和 Slave 之间通过同步复制或异步复制的方式进行数据同步。同步复制可以保证数据的强一致性，但可能会影响系统的性能；异步复制则可以提高系统的吞吐量，但在 Master 故障时可能会丢失少量数据。通过合理配置复制方式，可以在可用性和数据一致性之间找到平衡。
3. 负载均衡：多个 Broker 节点（包括 Master 和 Slave）共同组成一个集群，通过 NameServer 提供的路由信息，生产者和消费者可以将请求均匀地分配到各个 Broker 节点上，实现负载均衡，避免单个 Broker 节点压力过大，从而提高整个系统的可用性。

协同保证可用性

1. Broker 与 NameServer 交互：Broker 定期向 NameServer 发送心跳包，以维持连接并告知 NameServer 自身的存活状态。如果 NameServer 在一定时间内未收到某个 Broker 的心跳，会将其从路由表中剔除。这样，当 Broker 出现故障时，NameServer 能够及时感知并通知客户端，客户端可以重新获取最新的路由信息，连接到其他可用的 Broker。
2. Master - Slave 切换：当 Master Broker 发生故障时，监控系统（如 RocketMQ 自带的监控工具或第三方监控系统）会检测到异常，并触发切换流程。将某个 Slave Broker 提升为 Master，同时更新 NameServer 中的路由信息，使生产者和消费者能够重新连接到新的 Master 继续进行消息的生产和消费，从而保证系统的高可用性。