保证MQ的高可用性，主要是解决MQ的缺点--系统复杂性变高--带来的问题
主要说一下 rabbitMQ 和 kafka 的高可用性
一、rabbitMQ的高可用性
rabbitMQ是基于主从做高可用性的，主要有三种模式：单机模式（不推荐）、普通集群模式（不推荐）、镜像集群模式（推荐）
1、单机模式：demo级别，本地启动，个人练习使用的，生产环境一般不用
2、普通集群模式：
多台机器上启动多个rabbitMQ实例，但是你创建的queue（元数据+实际数据）只会放在一个rabbitMQ实例 A 上，其他实例都会同步queue的元数据（元数据可以理解为queue的位置、信息，便于其他实例拉取数据的）。如果消费者消费信息的时候，实际连接的是另一个实例 B ，那个B会根据元数据去到A上拉取数据过来。
缺点是：没做到所谓的分布式，就是个普通集群。
消费者每次随机连接一个实例拉取数据（增加了拉取数据的开销），
要么就是消费者固定连接到那个queue所在的实例消费数据（导致单实例性能瓶颈）。
若A宕机了（丢失数据），则其他实例无法拉取数据。即使开启了消息持久化，让rabbitMQ落地存储消息，消息不一定会丢，得等A恢复了才能继续拉取数据。
总结：并没有高可用性可言。该方案主要是提高吞吐量，让集群中多个节点来服务某个queue的读写操作。
3、镜像集群模式：rabbitMQ的高可用实现
创建一个queue（元数据+实际数据），无论是queue的元数据还是消息，都存在于多个实例上。每次写消息到queue时，都会自动把消息同步到多个实例的queue里。
好处是不担心宕机，因为所有实例的数据都是一样的。
坏处是（1）性能开销大，消息同步所有机器导致网络带宽压力和消耗很重；
（2）无扩展性可言，若某queue负载很重，你再加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性拓展你的queue（非分布式的）；
另：如何开启镜像集群模式？rabbitMQ管理控制台上新增一个镜像集群模式的策略，指定的时候可以要求数据同步到所有节点，也可以要求同步到指定数量的节点，然后在创建queue时应用这个策略，就会自动将数据同步到其他节点上。
二、kafka 的高可用性