• 消息的高可用
  • RabbitMQ的高可用
    • 单机模式
    • 普通集群模式(无高可用性)
    • 镜像集群模式(高可用)
    • 总结
  • Kafka高可用性

消息的高可用

RabbitMQ的高可用

基于主从（非分布式）做高可用

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

单机模式

Demo级别

普通集群模式(无高可用性)

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

这种方式很麻烦，没有做到分布式，就是个普通集群。导致消费者每次随机连接一个实例然后拉取数据，或者固定连接哪个队列所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。

如果放队列的实例宕机，会导致其他实例无法从这个实例拉去，若是开启了消息持久化，消息不一定会丢，等这个实例恢复就可以继续从这个队列中拉取数据。

所以并没有所谓的高可用，只是提高吞吐量。

镜像集群模式(高可用)

这种模式才是真正的高可用模式。与普通集群模式不一样，在镜像集群模式，创建的队列，无论事元数据还是队列里的消息都会存在多个实例伤，也就是每个RabbitMQ节点都有这个队列完整的一个镜像，包含队列的全部数据。每次写消息到队列的时候，都会自动把消息同步到多个实例。

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

这样任何一个机器宕机，其他节点还包含了这个队列的完整数据，别的消费者都可以到其他节点去消费数据。但是

1. 性能开销太大，消息需要同步到所有节点，导致网络带宽压力消耗较大
2. 没有扩展性可言，如果其中一个队列的负载很重，加机器也没有办法扩展

总结

• 单机模式 Demo级别，本地操作
• 普通集群模式 消费者每次随机连接一个实例然后拉取数据，或者固定连接哪个队列所在实例消费数据，不算是高可用模式，需要拉取数据，还容易丢失消息。
• 镜像集群模式 你创建的队列，数据数据队列里的任何消息都存在于多个实例上。（常用）

Kafka高可用性

由多个broker组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition存放一部分数据。

topic的数据，是分散在多个机器上，每个机器就放一部分数据。

• Kafkfa 0.8以前，没有HA机制，任何一个broker宕机，那么 broker 上的 partition 就废了，没法写也没法读。
• Kafkfa 0.8以后，提供HA机制，就是replica(复制品)副本机制。每个partition数据都会同步到其他机器，形成自己的replica副本。所有replica会选举一个leader出来，那么生产和消费者都跟这个leader打交道，其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候直接在leader读数据就可以了。

只能读写leader？要是可以随意读写每个follower，那么就要关心数据一致性问题，系统复杂度太高，很容易出问题。。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的时候，这个消息才会被消费者读到。