如何保证消息队列高可用

首先MQ会导致系统可用性降低，所以只要你用了MQ，那就一定有缺点了

RabbitMQ的高可用性

RabbitMQ是比较有代表性的，因为是基于主从（非分布式）做高可用的，我们就以RabbitMQ为例子讲解第一种MQ的高可用是怎么实现

RabbitMQ有三种模式：单机，普通集群，镜像集群

单机模式

单机模式，玩具罢了

普通集群模式（没有高可用性）

普通集群模式，意思就是在多台机器上启动多个RabbitMQ实例，每个机器启动一个。你创建的queue，只会放在一个RabbitMQ实例上，但是每个实例都同步queue的元数据（元数据可以认为是queue的一些配置信息，通过元数据，可以找到queue所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据

这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈

这就很尴尬了，没有所谓的高可用性，这方案主要是提高吞吐量的

镜像集群模式（高可用性）

这种模式，才是所谓的RabbitMQ的高可用模式，就是raft嘛。每个RabbitMQ节点都有这个queue的一个完整镜像，包含queue的全部数据的意思。然后每次你写消息到queue的时候，都会自动把消息同步到多个实例的queue上。

• 好处：任何一个机器宕机了，没事儿，其他机器（节点）还包含了这个queue的完整数据，别的consumer都可以到其他节点上去消费数据
• 坏处：
  1. 性能开销太大了，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！
  2. 不是分布式的，就没有扩展性可言了

kafka的高可用性

kafka一个最基本的架构认识：由多个broker组成，每个broker是一个节点。你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据

这就是天然的分布式消息队列，就是说一个topic的数据，是分散在多个机器上的，每个机器就放一部分数据

实际上RabbitMQ之类的，并不是分布式消息队列，只不过提供一些集群，HA（High Availability，高可用）机制

kafka 0.8之前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法读也没法写

kafka 0.8以后，提供了HA机制，就是replica（复制品）副本机制。每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上的数据