集群级高可用能力说明
消息队列 MQTT 版提供集群级高可用能力，通过跨可用区部署有效提升消息服务的稳定性和容灾能力。
在购买 MQTT 实例时，只需要选择 MQTT 集群所在的地域，服务端在创建集群时默认就会按照多个可用区进行部署。
跨可用区部署
部署架构
MQTT 的跨可用区部署架构分为网络层、数据层和控制层。
网络层
MQTT 会为客户端暴露多个集群接入地址，以域名的形式对外。客户端在连接到集群接入地址后，会和 MQTT 数据层进行通信。这是一个可以随时 failover 到其他可用区的域名，当某个可用区不可用时，域名后端的服务会切换到同地域其他可用的节点，从而实现跨可用区容灾。
数据层
MQTT 的数据面进行分布式部署方式，即数据面的多个组件都跨可用区部署。
Proxy 组件是无状态的，当某个可用区（如AZ1）的Proxy或者可用区整体出现故障时，服务端会自动将其从后端服务器池中剔除，并尝试建立新的 Proxy 节点。所有新的客户端连接和请求都会无缝转发到其他存活可用区（如 AZ2 和 AZ3）的 Proxy 节点上。对于客户端而言，它始终只与一个统一的域名（上述的集群接入地址）通信。它完全不知道后端 Proxy 发生了故障切换，无需修改任何配置或重启应用。可能只会观察到一次非常短暂（秒级）的网络抖动或超时，然后自动恢复。当 AZ1 恢复后，服务端的健康检查会重新探测到其 Proxy 实例已健康，并逐步将其加回服务器池，重新接收流量。
Broker 负责消息的存储，因为客户端并不支持和 Broker 节点进行通信，对客户端来说并不直接感知 Broker 的健康状态。当某个可用区（如AZ1）的 Broker 或者可用区整体出现故障时，NameServer 集群中的路由信息会被更新，指示所有主题的该队列现在由新的，如 AZ2 的 Broker 节点提供服务，所有 Proxy 节点会从 NameServer 拉取最新的路由信息，从而将新的客户端请求路由到 AZ2 的 Broker 节点。
控制层
同理，MQTT 的控制台部署也满足跨可用区的要求，管控节点不承担数据流，每个地域部署一套管控服务。
数据高可用
腾讯云消息队列 MQTT 版的优势之一就是对于消息持久化的存储。
客户端收到服务端的 PUBACK（QoS=0或1）或PUBCOMP（QoS=2）后表示消息发送成功，服务端已经收到消息。服务端收到消息后，将会把消息持久化存储到 Broker 节点的云盘内。Broker 节点本身有跨可用区容灾的功能，另外借助云盘的备份点和副本存储能力，因此消息的持久化和数据的高可用有了“双保险”的加持。即使在全地域 Broker 节点宕机后，已存储的消息依然会被保存。
