消息队列（二）如何保证消息队列的高可用？

在上一篇笔记 【MQ 学习笔记】为什么要使用消息队列？ 中，介绍了消息队列的应用场景和可能导致的问题，其中高可用问题是引入 MQ 的第一个问题。

一、什么是高可用性？

对于高可用性，维基百科上是这么描述的：高可用性（英语：high availability，缩写为 HA），IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。

也就是说，我们不可能做到 100% 的可用性，所以用可用性度来表示高可用性，通常我们会用多少个 9 来表示高可用的目标，比如 99.99% 表示系统的年停机时间为 8.76 个小时，也就是 99.99% 的时间都是可用的。要做到高可用，我们至少要实现下面两点：

• 对软硬件的冗余备份，以消除单点故障。

• 对故障的检测和恢复。

二、如何保证消息队列的高可用

不同的消息队列，保证高可用的方式有一些区别，这里分别记录下各种消息队列的高可用实现方式。

1、RocketMQ 高可用

RocketMQ 进程我们一般称为 Broker，Broker 通常是集群部署的，每个 Broker 需要注册到 NameServer 中。从这里我们可以知道高可用有两个地方需要解决，一是 Broker 挂了怎么办，二是 NameServer 挂了怎么办。

对于 NameServer，它的高可用保障是集群化部署，各个 NameServer 之间互不通信，每个 NameServer 都有一份完整的 Broker 路由信息。当某一个 NameServer 挂掉后，对集群没有任何影响，只要还有一个 NameServer 存活，就能提供完整的服务。

对于 Broker，它高可用保障是主从架构和多副本策略。Broker 有 Master 和 Slave 两种角色，Master 和 Salve 上的数据是一模一样的，Master Broker 收到消息后会同步给 Slave Broker。每个 Master Broker 和 Slave Broker 都会向所有 NameServer 注册。Master 宕机了，会重新选举一个 Slave 作为 Master 继续提供写服务，对读服务无影响，每个 Slave 都可以读但是不可以写；Slave 宕机了，对服务无影响。

RocketMQ 的高可用保障如下图：

2、RabbitMQ 高可用

RabbitMQ 不是分布式的，它有三种模式：单机模式、普通集群模式、镜像集群模式。其中只有镜像集群模式是能够保障高可用的，而生产环境不会使用单机模式。

• 普通集群模式：集群中所有节点都存储队列元数据，但是只有一个节点存队列内容，此节点宕机则数据会丢失

• 镜像集群模式：集群中每个节点都存储完整的队列元数据和队列内容，是一份完整的镜像数据。某个节点宕机，对整体服务没有影响。缺点是不支持分布式，每台机器都有一份完整的数据。

3、Kafka 高可用

Kafka 高可用与 RocketMQ 类似，都是通过主从多备份架构实现的。如下图，每个 leader broker 可以有多个 follower broker，生产者生产和消费者消费均操作 leader broker 节点，当 leader broker 宕机后自动切换 follower 为 leader。

三、总结

本文先是描述了什么是高可用，以及不同 MQ 是怎么实现高可用的。要做到高可用，就要考虑容灾问题，如单点故障和数据丢失。单点故障我们通过集群来实现，如 RabbitMQ 的镜像集群模式，RocketMQ 的 NameServer 集群和 Master Broker 集群，Kafka 的 Zookeeper 集群和 Leader Broker 集群，这些集群每个节点都有一份完整的数据；数据丢失则只能通过数据镜像来实现了，如 RocketMQ 的 Master-Slave，Kafka 的 Leader-Follower，一般工业界认为比较安全的备份数应该是 3 份，所以一般至少会1主2从。