浅谈消息队列的高可用性

注：该文是本博主记录学习之用，没有太多详细的讲解，敬请谅解！

一、RabbitMQ的高可用性

RabbitMQ是基于主从模式实现高可用，有三种模式：单机模式、普通集群模式，镜像集群模式。

1. 单机模式
   普通单机模式 ，一般本地demo用，没有特别之处。

2. 普通集群模式
   普通集群模式意思就是多台服务器启动多个RabbitMQ实例，一个服务器一个实例。创建的queue只会放到一个RabbitMQ实例上，其他实例同步queue的元数据，这样的方式就会导致出现两种情况：
   1）消费者每次随机连接一个实例然后拉取数据，有数据拉取的性能开销。
   2）要么固定连接那个queue所在实例消费数据，存在单实例的性能瓶颈。

如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让RabbitMQ落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。

这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

架构图如下所示：

3. 镜像集群模式
   镜像集群模式就是创建的queue会存在于多个实例中，每次写消息到queue中都会同步到其他实例中，由此实现高可用。但是也导致有其他问题出现，
   1）性能开销太大，消息同步所有机器，导致网络带宽压力和消耗很重。
   2）扩展性低，如果某个queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展queue。

架构图如下所示：

二、Kafka的高可用性

kafka是一个典型的分布式消息队列，它由多个broker组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。

kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。

kafka 0.8以后，提供了HA机制，就是replica副本机制：

• 每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。
• 然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道。
• 其他replica就是follower。

架构图如下所示：

三、RocketMQ的高可用性

RocketMQ也是基于Master/Slave模式实现高可用，在集群模式的部署方式中，Master与Slave配对是通过指定相同的brokerName参数来配对，Master的BrokerId必须是0，Slave的BrokerId必须是大于0的数。一个Master下面可以挂载多个Slave，同一个Master下的多个Slave通过指定不同的BrokerId来区分。
RocketMQ有四种部署模式：

1. 单个Master模式
   一旦Broker重启或者宕机时，会导致整个服务不可用。

2. 多个Master模式

   优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。

   缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会收到影响。

   备注：当使用多master无slave的集群搭建方式时，master的brokerRole配置必须为ASYNC_MASTER。如果配置为SYNC_MASTER，则producer发送消息时，返回值的SendStatus会一直是SLAVE_NOT_AVAILABLE。

3. 多Master多Slave模式—异步复制

   优点：即使磁盘损坏，消息丢失的非常少，但消息实时性不会受影响，因为Master宕机后，消费者仍然可以从Slave消费，此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样。

   缺点：Master宕机，磁盘损坏情况，会丢失少量信息。

架构图如下所示：

4. 多Master多Slave模式—同步双写

   优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高。

   缺点：性能比异步复制模式稍低，大约低10%左右，发送单个消息的RT会稍高，目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。

架构图如下所示：

在集群模式下，为了保证高可用，必须要保证备用Broker与主用Broker信息是一致的，在备用Broker初始化时设置的了定时任务，每个60秒调用SlaveSynchronize.syncAll()方法发起向主用Broker进行一次config类文件的同步，而消息数据的同步由主备Broker通过心跳检测的方式完成，每隔5秒进行一次心跳。 主用Broker提供读写服务，而备用Broker只提供读服务。

注：以上内容都是从网上各博客中学习而写，如果侵犯版权，敬请见谅！