消息中间件的高可用

RabbitMQ 的高可用性

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的。

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

单机模式： Demo 级别、本地启动，生产不使用该模式

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

缺点：普通集群提高吞吐量，没有分布式，不存在高可用性

镜像集群模式（高可用性）：创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上。每个 RabbitMQ 节点都有 queue 的一个完整镜像，包含 queue 的全部数据。然后每次写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。

 

如何开启镜像集群模式？

在 RabbitMQ后台新增 镜像集群模式的策略， 指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

优点：某一台宕机其他机器仍可以继续被消费。

缺点：性能开销大、扩展性低

 

Kafka 的高可用性

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

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

Kafka 0.8 以前，是没有 HA 机制的，就是任何一个 broker 宕机了，那个 broker 上的 partition 就废了，没法写也没法读，没有什么高可用性可言。
比如说，我们假设创建了一个 topic，指定其 partition 数量是 3 个，分别在三台机器上。但是，如果第二台机器宕机了，会导致这个 topic 的 1/3 的数据就丢了，因此这个是做不到高可用的。

 

Kafka 0.8 以后，提供了 HA 机制，就是 replica（复制品） 副本机制。

每个partition都会将自己的数据同步到其他机器上，形成记得多个副本。选举一个leader<红色>，生产和消费都只和leader交互，其他副本都是follower<绿色>。
Kafka 会均匀地将一个 partition 的所有 replica 分布在不同的机器上，这样才可以提高容错性。

这样每个partition在多个机器上都存在副本，如果leader宕机了，再从follower中选举新的leader。就凸显出了高可用性。

写数据的时候，生产者就写 leader， leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。

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

来源：oschina

链接：https://my.oschina.net/AnniHome/blog/3165137