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

场景的两头件有不少品种型，正在这里就预备罕用的一些就用于剖析解决。

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 的时分，这个音讯才会被生产者读到。

更多相干php常识，请拜访php教程！

以上就是若何保障音讯行列步队的高可用？的具体内容，更多请存眷资源魔其它相干文章！