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

消息队列在高并发的场景是必备技能，随着咱们的使用，在生产环境中的问题也是很是的多，好比：消息队列如何作到高可用呢？
场景的中间件有不少种类型，在这里就准备经常使用的一些就用于分析处理。

1. RabbitMQ 的高可用性

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

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

单机模式

单机模式，就是 Demo 级别的，通常就是你本地启动了玩玩儿的，没人生产用单机模式。

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

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

 

 

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

并且若是那个放 queue 的实例宕机了，会致使接下来其余实例就没法从那个实例拉取，若是你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不必定会丢，得等这个实例恢复了，而后才能够继续从这个 queue 拉取数据。

因此这个事儿就比较尴尬了，这就没有什么所谓的高可用性，这方案主要是提升吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操做。

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

这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不同的是，在镜像集群模式下，你建立的 queue，不管元数据仍是 queue 里的消息都会存在于多个实例上，就是说，每一个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的所有数据的意思。而后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。

 

 

那么如何开启这个镜像集群模式呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是能够要求数据同步到全部节点的，也能够要求同步到指定数量的节点，再次建立 queue 的时候，应用这个策略，就会自动将数据同步到其余的节点上去了。

这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 均可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息须要同步到全部机器上，致使网络带宽压力和消耗很重！第二，这些玩儿，不是分布式的，就没有扩展性可言了，若是某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的全部数据，并没有办法线性扩展你的 queue。

2. Kafka 的高可用性

Kafka 一个最基本的架构认识：由多个 broker 组成，每一个 broker 是一个节点；你建立一个 topic，这个 topic 能够划分为多个 partition，每一个 partition 能够存在于不一样的 broker 上，每一个 partition 就放一部分数据。

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

实际上 RabbmitMQ 之类的，并非分布式消息队列，它就是传统的消息队列，只不过提供了一些集群、HA(High Availability, 高可用性) 的机制而已，由于不管怎么玩儿，RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每一个节点都放这个 queue 的完整数据。

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

好比说，咱们假设建立了一个 topic，指定其 partition 数量是 3 个，分别在三台机器上。可是，若是第二台机器宕机了，会致使这个 topic 的 1/3 的数据就丢了，所以这个是作不到高可用的。

 

 

Kafka 0.8 之后，提供了 HA 机制，就是 replica（复制品） 副本机制。每一个 partition 的数据都会同步到其它机器上，造成本身的多个 replica 副本。全部 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，而后其余 replica 就是 follower。写的时候，leader 会负责把数据同步到全部 follower 上去，读的时候就直接读 leader 上的数据便可。只能读写 leader？很简单，要是你能够随意读写每一个 follower，那么就要 care 数据一致性的问题，系统复杂度过高，很容易出问题。Kafka 会均匀地将一个 partition 的全部 replica 分布在不一样的机器上，这样才能够提升容错性。

 

 

这么搞，就有所谓的高可用性了，由于若是某个 broker 宕机了，没事儿，那个 broker上面的 partition 在其余机器上都有副本的。若是这个宕机的 broker 上面有某个 partition 的 leader，那么此时会从 follower 中从新选举一个新的 leader 出来，你们继续读写那个新的 leader 便可。这就有所谓的高可用性了。

写数据的时候，生产者就写 leader，而后 leader 将数据落地写本地磁盘，接着其余 follower 本身主动从 leader 来 pull 数据。一旦全部 follower 同步好数据了，就会发送 ack 给 leader，leader 收到全部 follower 的 ack 以后，就会返回写成功的消息给生产者。（固然，这只是其中一种模式，还能够适当调整这个行为）

消费的时候，只会从 leader 去读，可是只有当一个消息已经被全部 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。