2. MQ如何保证其高可用

RocketMQ 保证其高可用

RocketMQ 分布式集群是通过Master和Slave的配合达到高可用性的，Master 角色的 Broker 支持读和写，Slave 角色的 Broker 仅支持读，也就是 Producer 只能和 Master 角色的 Broker 连接写人消息；Consumer 可以连接 Master 角色的 Broker，也可以连接 Slave 角色的 Broker 来读取消息

消费端的高可用性

Master 不可用或者繁忙的时候，Consumer 会被自动切换到从 Slave 读。有了自动切换Consumer这种机制，当一个 Master 角色的机器出现故障后，Consumer 仍然可以从 Slave 读取消息，不影响Consumer 程序。这就达到了消费端的高可用性。

发送端的高可用性

在创建 Topic 的时候，把 Topic 的 MessageQueue 创建在多个 Broker 组上（相同Broker名称，不同brokerId的机器组成一个Broker组），这样当一个 Broker 组的 Master 不可用后，其他组的 Master 仍然可用，Producer 仍然可以发送消息。

---

Kafka 保证其高可用

Kafka 有多个 broker，每个broker 就是一个节点

KafKa每创建一个Topic，这个Topic 可以划分为多个partition，每个partition 可以存在于不同的 broker 中，每个partition 中只放部分数据，保证了Kafka的分布式部署

Kafka引入了副本机制 replica ，每个partition 都会将消息同步到其他的机器上，然后从这些机器通过ZK的leader的选举方式出来一个leader，其他的作为follower，读写在leader上进行操作。即便是leader 宕机了，会从剩余的follower中再次快速选举出来一个leader，保证高可用

RabbitMQ 保证其高可用

RabbitMQ集群部署：（普通集群部署和镜像集群部署）
RabbitMQ不支持分布式部署，因为RabbitMQ的数据是全部放在一台机器上的

普通集群部署：

将一个RabbitMQ的实例放到多个机器上，创建的MQ的queue只会放在一个RabbitMQ的实例上，其他的MQ去同步这个机器上的实例，但是只是同步的元数据，元数据标识了这个数据所在的机器等信息，当消费者消费到了元数据，会根据元数据找到对应的实例数据

缺点：实例宕机对消息消费的影响较大

优点：提高吞吐量，因为对应的是集群

镜像集群模式

创建的元数据和queue中的消息都会存在于多个机器上，能保证高可用，即便是一个机器宕机，也能保证其他的机器继续服务于消费者和生产者

缺点：性能开销大，一直在同步消息；消息存在于一台机器上，消息积压不好处理