MQ（消息队列）系列学习---MQ如何保证消息队列高可用

前言

这是一个MQ的系列文章，主要由MQ的基础认识到深入了解，和针对不同业务对MQ的技术选型问题。通过文章了解不同MQ的各种区别，和使用MQ会存在的一些问题。

入门篇：MQ（消息队列）系列学习—MQ基础认识
基础篇：MQ（消息队列）系列学习—MQ组件优劣势比较
晋级篇：MQ（消息队列）系列学习—MQ如何保证消息队列高可用
在我们选择了一个技术框架后，我们不光要掌握它的日常使用，也要了解因为这个选型而出现的问题，并未这些问题做好相应的方法备案。而这些知识都是使用该组件会碰见的问题，也是面试必备的问题。

如何保证消息队列是高可用的？

在系统中引入了会导致系统的复杂程度增加，如果系统的中间件挂掉后会导致系统中有依赖的内容崩溃，那么保证系统的高可用性就是必不可少的。

在生产中，消息队列一般都是使用使用集群来实现高可用。但对于不同的MQ的会有不同的集群模式，如RabbitMQ的集群模式为单机模式，普通集群模式，镜像集群模式、RocketMQ的集群方式为多个master集群、多Master多Slave模式-异步复制、多Master多Slave模式-同步双写。

1 RabbitMQ实现高可用

1.1 普通集群（无高可用性，可提高吞吐量）

多台MQ上启动多个RabbitMQ的实例，你使用的queue只会在某一个RabbitMQ的实例上，但是每个实例都会去同步queue的元数据（就是一些配置信息，通过元数据就可以找到queue所对应的实例）。如果你消费的时候，如果连接了其他实例（其他实例中并没有queue需要的数据），那么当前实例就通过元数据，找到对应的实例中的queue然后进行拉取数据。
优点：
提高了吞吐量
缺点：
不能保证高可用性，当 放queue的实例挂掉后，就会造成数据丢失。

1.2 镜像集群（高可用，但不能提高吞吐量）

该模式与普通模式的区别为：不光会进行同步元数据也会同步queue数据，每个MQ实例中的queue数据都是相同的。所以在随意一台的MQ宕机后，也能去其他MQ实例进行正常消费。
优点：
实现了高可用
缺点：
1.因为会将所有数据进行同步，如果一个queue过大，同步的性能消耗也会过高。
2.不能扩展，每台实例数据一样的，不能通过增加实例来解决

2 RocketMQ实现高可用

RocketMQ的集群方式为多个master集群、多Master多Slave模式-异步复制、多Master多Slave模式-同步双写。
RocketMq中由NameServer 集群、Broker 集群、Producer 集群和 Consumer 集群：
NameServer: 提供轻量级的服务发现和路由。 每个 NameServer 记录完整的路由信息，提供等效的读写服务，并支持快速存储扩展。
Broker: 通过提供轻量级的 Topic 和 Queue 机制来处理消息存储,同时支持推（push）和拉（pull）模式以及主从结构的容错机制。
Producer：生产者，产生消息的实例，拥有相同 Producer Group 的 Producer 组成一个集群。
Consumer：消费者，接收消息进行消费的实例，拥有相同 Consumer Group 的Consumer 组成一个集群。

简单说明一下图中箭头含义，从 Broker 开始，Broker Master1 和 Broker Slave1 是主从结构，它们之间会进行数据同步，即 Date Sync。同时每个 Broker 与NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer 中。

Producer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker master，但是 Consumer 则不一样，它同时和提供 Topic 服务的 Master 和 Slave
建立长连接，既可以从 Broker Master 订阅消息，也可以从 Broker Slave 订阅消息。

2.1 多个master集群多Master模式

全是Master，无Slave。某个实例挂了，该实例在重启前未被消费的消息无法被消费

优点：配置简单，性能最高
缺点：单台机器重启或宕机期间，该机器下未被消费的消息在机器恢复前不可订阅，影响消息实时性

2.2. 多Master多Slave异步模式（一般生产环境使用）

每个Master配一个Slave，有多对Master-Slave，集群采用异步复制方式，主备有短暂消息延迟，毫秒级

优点：性能同多Master几乎一样，实时性高，主备间切换对应用透明，不需人工干预
缺点：Master宕机或磁盘损坏时会有少量消息丢失

2.3. 多Master多Slave同步模式（对数据可靠性要求高时使用）

每个Master配一个Slave，有多对Master-Slave，集群采用同步双写方式，主备都写成功，才向应用返回成功

优点：服务可用性与数据可用性非常高
缺点：性能比异步集群略低（大约低10%），当前版本主宕备不能自动切换为主
需要注意的是，在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置里面，就定死了。

其中Master的broker id = 0，Slave的broker id > 0。有点类似于mysql的主从概念，Master挂了以后，Slave仍然可以提供读服务，但是由于有多主的存在，当一个Master挂了以后，可以写到其他的Master上。
Rocket转载于：云原生实战