腾讯云 TDMQ RocketMQ 版采用“多主架构（Multi-Master）+ 跨可用区部署”保障服务高可用，同时利用“云盘三副本”机制保障数据高可用。 这种架构摒弃了传统的 Master-Slave 模式，极大地简化了运维复杂性，并提供了金融级的可靠性。
集群高可用
集群高可用的核心目标是：确保即使部分组件发生故障，整个消息服务依然能够对外提供不间断的读写服务。腾讯云 TDMQ RocketMQ 版通过 “NameServer 集群 + 无状态 Proxy + Broker 多主 + 跨可用区部署”的组合，构建了无单点故障、具备区域级容灾能力的高可用服务集群。
NameServer 集群化与跨可用区部署
NameServer 是 RocketMQ 的“大脑”，负责服务发现和路由管理。它本身必须是高可用的。在腾讯云方案中：
集群化部署：至少部署 2 个 NameServer 节点，组成一个无状态的集群。
跨可用区（AZ）部署：将这些 NameServer 节点分散部署在同一地域下的多个不同可用区。可用区是物理隔离的数据中心，一个可用区的故障不会影响其他可用区。
这样，任何一个 NameServer 节点甚至整个可用区的故障，都不会影响路由信息的获取，Producer 和 Consumer 依然可以从其他健康的 NameServer 节点获取到 Broker 的地址列表。
Broker 多主（Multi-Master）架构
与传统的 Master-Slave 架构不同，多主架构下，没有主从之分，所有 Broker 节点都是 Master，都可以随时接收生产者的消息写入请求。
读写负载均衡
Producer 在发送消息时，会从 NameServer 获取所有可用的 Master Broker 列表，并采用轮询等策略将消息写入不同的 Broker，天然实现了写入流量的负载均衡。
无缝故障转移
单节点故障：当某个 Broker 节点因宕机或网络问题与 NameServer 心跳中断时，NameServer 会立即将其从路由表中剔除。
客户端自动重试：Producer 和 Consumer 会定时从 NameServer 更新 Broker 列表。当它们发现某个 Broker 不可用时，会自动跳过该节点，将请求（如消息发送、消息拉取）无缝切换到集群中其他健康的 Broker 节点上。
整个过程对业务应用完全透明，无需人工干预，实现了秒级的故障转移。
跨可用区（Cross-AZ）部署 Broker
为了应对数据中心级别的灾难，我们将多个 Master Broker 节点分散部署在不同的可用区。根据用户的可用区选择，强制跨可用区分布。
故障场景模拟
假设集群部署在广州地域的三个可用区（AZ1、AZ2、AZ3），每个可用区都有 Broker 节点。
场景一：AZ1 的某台 Broker 服务器宕机。
NameServer 侦测到心跳超时，将该 Broker 从路由信息中移除。
新的生产和消费请求会自动路由到 AZ1 的其他 Broker 以及 AZ2、AZ3 的 Broker 上，服务不中断。
场景二：AZ1 整个可用区因电力或网络故障完全不可用。
所有位于 AZ1 的 NameServer 和 Broker 节点都将离线。
由于 NameServer 和 Broker 在 AZ2 和 AZ3 仍有健康的节点，客户端会连接到这些节点上。
整个集群的服务能力会暂时下降，但核心的收发消息功能依然可用，保证了业务的连续性。
跨可用区（Cross-AZ）部署 Proxy
针对 5.x 的产品形态，我们也和 Broker 一样，根据用户的可用区选择，强制跨可用区分布。基于 Proxy 的“无状态”特性。这意味着：
不存储业务数据：消息数据、消费位点（Offset）等持久化状态信息依然存储在 Broker 的云盘上。
不维持长会话状态：Proxy 自身不保存关键的、不可恢复的会话信息。任何一个 Proxy 节点都可以处理任何一个客户端的请求。
同时在部署层面，采用多节点集群 + 前置负载均衡（Load Balancer）。
部署多个 Proxy 实例：我们会部署至少 3 个或更多的 Proxy 实例，并将它们像 NameServer 和 Broker 一样，分散在不同的可用区。
配置前置负载均衡器（LB）：在所有 Proxy 实例的前方，我们会配置一个负载均衡器（例如腾讯云的 CLB）。这个 LB 对外提供一个唯一的虚拟 IP（VIP）地址。
客户端连接 VIP：所有的 Producer 和 Consumer 客户端，不再直接连接 NameServer 或 Broker，而是只配置并连接这个统一的 LB VIP 地址。
数据高可用
数据高可用是消息队列的生命线，其目标是确保已成功写入的消息数据不会因任何硬件故障而丢失。传统 RocketMQ 依赖 Master-Slave 同步复制（SYNC_FLUSH）来保证数据不丢，但这带来了性能开销大、主从切换复杂等问题。
腾讯云利用了 IaaS 层的能力，通过云硬盘（CBS）的三副本机制，从根本上解决了数据持久化的高可用问题。
“Broker + 云盘三副本”的模式，是一种典型的计算存储分离架构。它将 RocketMQ Broker 变成了一个“无状态”的计算节点，而将“有状态”的数据存储交给了专业、高可用的分布式块存储服务，从而实现了数据的高可用。
什么是云盘三副本？
云硬盘（Cloud Block Storage, CBS）是腾讯云提供的一种高可用、高可靠、低时延的网络块存储设备。其核心特性之一就是，数据三副本机制。
当 RocketMQ Broker 向其挂载的云盘写入一条消息数据（CommitLog/ConsumeQueue）时，云盘的底层存储系统会自动、同步地将这份数据写入到同一可用区内三个不同物理机架上的三份物理拷贝。
只有当三份拷贝都成功写入后，写操作才会向上层应用（即 RocketMQ Broker）返回成功。
这个过程对上层应用是完全透明的，Broker 只是在进行一次普通的本地磁盘写入。
云盘三副本如何保障数据高可用？
这种架构将数据可靠性的保证，从应用层（RocketMQ Master-Slave 复制）下沉到了更可靠、更高效的基础设施层（分布式存储）。
无惧单盘/单机故障
任何一个数据副本所在的物理磁盘或服务器发生故障，系统会自动从另外两个健康的副本中恢复数据，并选择一个新的位置创建新的副本，始终保持三副本状态。整个过程对业务无感知，数据零丢失。
简化架构，告别主从复制
由于数据在存储层已经实现了高可用，我们不再需要部署 Slave 节点，也无需配置复杂的 Master-Slave 同步复制。这带来了巨大优势：
无复制延迟：不存在主从之间的数据同步延迟问题。
运维极简：无需处理主从切换、数据补齐等复杂的运维场景。
快速恢复：当 Broker 节点（虚拟机）故障后，我们只需启动一个新的 Broker 实例，并重新挂载原来的云盘。由于所有消息数据都完好无损地保存在云盘上，Broker 实例可以立即恢复服务，恢复时间（RTO）大大缩短。
容器化部署
在上述高可用架构的基础上，如果我们将整个 RocketMQ 集群（包括 NameServer 和 Broker）进行容器化部署，并运行在以腾讯云 TKE（Tencent Kubernetes Engine）为代表的容器编排平台上，可以实现标准化交付、快速的扩容、以及异常场景下的自动恢复。
