消息队列（二）如何保证消息队列的高可用？
消息队列高可用靠消除单点故障和数据镜像实现：RocketMQ 通过 NameServer 集群加 Broker 主从（Master-Slave）架构，Master 宕机重新选举；RabbitMQ 依赖镜像集群模式，每个节点保存完整队列数据；Kafka 采用 Leader-Follower 多副本，leader 宕机自动切换。工业界一般认为数据备份 3 份即 1 主 2 从较为安全。
- 高可用需消除单点故障并具备故障检测恢复能力
- NameServer 集群互不通信，每台持有完整路由信息
- Broker 采用主从架构，Master 宕机重新选举继续写服务
- RabbitMQ 仅镜像集群模式可保障高可用
- 工业界一般认为数据备份 3 份即 1 主 2 从较安全
一、什么是高可用性？
对于高可用性，维基百科上是这么描述的：高可用性（英语：high availability，缩写为 HA），IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。
也就是说，我们不可能做到 100% 的可用性，所以用可用性度来表示高可用性，通常我们会用多少个 9 来表示高可用的目标，比如 99.99% 表示系统的年停机时间为 8.76 个小时，也就是 99.99% 的时间都是可用的。要做到高可用，我们至少要实现下面两点：
对软硬件的冗余备份，以消除单点故障。
对故障的检测和恢复。
二、如何保证消息队列的高可用
不同的消息队列，保证高可用的方式有一些区别，这里分别记录下各种消息队列的高可用实现方式。
1、RocketMQ 高可用
RocketMQ 进程我们一般称为 Broker，Broker 通常是集群部署的，每个 Broker 需要注册到 NameServer 中。从这里我们可以知道高可用有两个地方需要解决，一是 Broker 挂了怎么办，二是 NameServer 挂了怎么办。
对于 NameServer，它的高可用保障是集群化部署，各个 Na
原创不易，完成人机校验，阅读全文
常见问题
RocketMQ 的高可用是怎么实现的？
NameServer 集群化部署且互不通信，各自持有完整路由信息；Broker 采用 Master-Slave 主从架构，Master 宕机重新选举继续提供写服务，Slave 可读不可写。
RabbitMQ 哪种模式能保证高可用？
只有镜像集群模式：每个节点都存完整队列元数据和内容，单节点宕机不影响整体服务；缺点是不支持分布式，每台机器都保存一份完整数据。
消息队列数据备份几份比较安全？
工业界一般认为比较安全的备份数是 3 份，即至少 1 主 2 从，如 RocketMQ 的 Master-Slave、Kafka 的 Leader-Follower 都靠多副本防止数据丢失。