RocketMQ高可用靠NameServer无状态兜底、Broker主从协同、存储分层保障三者配合实现；NameServer仅负责路由发现，Broker主从通过同步复制保障数据可靠，CommitLog顺序写入与混合刷盘提升吞吐与持久性。
RocketMQ 高可用集群不是靠单点扛压，而是靠组件分工+冗余设计+自动容错来实现的。核心在于 NameServer 轻量兜底、Broker 主从协同、消息存储分层保障，三者配合才能真正扛住故障和流量。
Nameserver：无状态路由中枢，故障不中断
NameServer 是整个集群的“通讯录”，不存消息、不参与收发，只管 Broker 的注册与发现。它天生无状态，节点之间不通信，也不做数据同步——这反而让它极轻量、易扩缩、难挂掉。
- Broker 每 30 秒向所有 NameServer 上报心跳，NameServer 在 120 秒未收到心跳时才剔除该节点
- Producer/Consumer 启动时拉取一次路由，之后每 30 秒主动刷新，即使某个 NameServer 暂时不可用，客户端也能轮询其他节点获取最新地址
- 生产环境建议至少部署 2 个 NameServer 实例，避免单点风险；无需配置一致性协议，天然支持 AP 架构
Broker 主从架构：读写分离 + 故障自动降级
Broker 是消息存储和转发的核心载体，高可用依赖于 Master-Slave 分组部署。同一 Broker 组内，brokerId=0 是 Master，brokerId>0 是 Slave，角色由配置文件明确指定。
- Master 支持读写，Slave 默认只读（可通过 slaveReadEnable=true 开启读负载），但不接受写请求
- 主从间通过同步复制（SYNC_MASTER）或异步复制（ASYNC_MASTER）保持数据一致；推荐生产环境使用 SYNC_MASTER，确保消息不因 Master 崩溃而丢失
- Consumer 自动识别 Master 状态：当 Master 不可用或响应慢时，会无缝切换到同组 Slave 拉取消息，无需修改配置或重启应用
- 注意：RocketMQ 不支持 Slave 自动升主，若 Master 宕机需人工干预——停 Slave、改 brokerId=0 和 brokerRole=SYNC_MASTER、重启
消息存储机制：CommitLog + 混合刷盘策略保可靠
RocketMQ 存储引擎采用统一 CommitLog 文件顺序写入，再通过 ConsumeQueue 和 IndexFile 提供高效检索，这种设计兼顾吞吐与可恢复性。
- 所有 Topic 消息都追加写入同一个 CommitLog 文件（默认 1GB 分片），避免磁盘随机写瓶颈，单机轻松支撑 10 万+ QPS
- 刷盘策略可配：ASYNC_FLUSH（性能高，断电可能丢少量消息）、SYNC_FLUSH（每次写入都 fsync，强持久但影响吞吐）；建议生产环境按业务容忍度选择
- 主从同步模式决定可靠性上限：ASYNC_MASTER 允许主写完即返回，Slave 异步追赶；SYNC_MASTER 要求 Slave 写成功后才确认，牺牲部分延迟换数据零丢失
- 消费位点（Offset）由 Consumer 自己管理并定期提交到 Broker，集群消费模式下 Broker 保存各 Consumer Group 的 Offset，避免重复或漏消费
Topic 与 MessageQueue：水平扩展与负载均衡基础
Topic 是逻辑分类，真正承载消息的是其下的 MessageQueue（类似 Kafka Partition）。数量与分布直接影响吞吐和容灾能力。
- 创建 Topic 时应将 MessageQueue 分散在多个 Broker 组上，例如 8 个队列分布在 4 个 Broker 组（每组一主一从），这样单组故障最多影响 25% 流量
- writeQueueNums 和 readQueueNums 建议设为相同值，否则可能出现消费者线程数不足导致消息堆积或漏拉
- Producer 默认轮询发送，Consumer 按 MessageQueue 均匀分配（集群模式下），天然支持横向扩容
