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

剖析

这个问题用的很好，不会具体到某个MQ，而是问一个整体，然后通过你使用的MQ，来具体谈谈该MQ的可用性的理解。

RabbitMQ高可用性

RabbitMQ是比较有代表性的，因为是基于主从做高可用性的。

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

单机模式

就是demo级别的，一般就是本地启动后玩一玩，没有人生产环境中使用。

普通集群模式

• 意思就是在多台机器上启动多个RabbitMQ实例，每台机器启动一个，但是创建的Queue，只会放在一个RabbitMQ实例上，但是每个实例都同步queue元数据，在消费的时候，实际上是连接到另外一个实例上，那么这个实例会从queue所在实例上拉取数据过来，这种方式确实很麻烦，也不怎么好，没做到所谓的分布式 ，就是个普通集群。因为这导致你要么消费每次随机连接一个实例，然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
• 而且如果那个放queue的实例宕机了，会导致接下来其它实例无法从那个实例拉取，如果 你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等到这个实例恢复了，然后才可以继续从这个queue拉取数据。

这里没有什么所谓的高可用性可言，这个方案主要就是为了解决吐吞量，就是集群中的多个节点来服务于某个queue的读写操作。

存在两个缺点

• 可能会在RabbitMQ中存在大量的数据传输
• 可用性没有什么保障，如果queue所在的节点宕机，就会导致queue的消息丢失

集群镜像模式

这种模式，才是RabbitMQ的高可用模式，和普通的集群模式不一样的是，你创建的queue无论元数据还是queue里的消息都会存在与多个实例中，然后每次你写消息到queu的时候，都会自动把消息推送到多个实例的queue中进行消息同步。

这样的好处在于，你任何一个机器宕机了，别的机器都可以用。坏处在于，性能开销提升，消息同步所有的机器，导致网络带宽压力和消耗增加，第二就是没有什么扩展性科研，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue

那么如何开启集群镜像策略呢？就是在RabbitMQ的管理控制台，新增一个策略，这个策略就是镜像集群模式下的策略，指定的时候，可以要求数据同步到所有的节点，也可以要求就 同步到指定数量的节点，然后再次创建queue的时候，应用这个策略，就会自动将数据同步到其它节点上去了。

集群镜像模式下，任何一个节点宕机了都是没问题的，因为其他节点还包含了这个queue的完整的数据，别的consumer可以到其它活着的节点上消费数据。

但是这个模式还存在问题：就是不是分布式的，如果这个queue的数据量很大，大到这个机器上的容量无法容纳的时候，此时应该怎么办呢？

kafka实现高可用

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

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

实际上RabbitMQ之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩，RabbitMQ一个queue的数据都放在一个节点里了，镜像集群下，也是每个节点都放这个queu的完整数据。

kafka0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法读也没办法写，没有什么高可用可言，而在0.8版本后，提供了HA机制，就是replica副本机制，每个partition的数据都会同步到其它机器上，形成自己的多个replica副本，然后所有的replica就是follower，写的时候，leader会负责数据都同步到所有的follower上，读的时候就直接读取leader上的数据即可。只能读写leader？很简单，要是你能随意读写每个follower，那么就需要保证数据一致性的问题，系统复杂度太高，很容易出问题，kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才能够提高容错性

每个副本不会存储节点的全部数据，而是数据可能分布在不同的机器上。

同时多个副本中，会选取一个作为leader，其它的副本是作为follower，并且只有leader能对外提供读写，同时leader在写入数据后，它还会把全部的数据同步到follower中，保证数据的备份。

此时，高可用的架构就出来了，假设现在某个机器宕机了，比如其中的一个leader宕机了，但是因为每个leader下还有多个follower，并且每个follower都进行了数据的备份，因此kafka会自动感知leader已经宕机，同时将其它的follower给选举出来，作为新的leader，并向外提供服务支持。