对于RabbitMQ，有三种模式，分别是单机模式，普通集群模式、镜像集群模式，其中镜像集群模式可以实现高可用
单机模式一台RabbitMQ实例，想想都不可能保证高可用，一般在开发中也不会使用单机模式
普通集群模式有多台RabbitMQ实例，每个都放在单独的机器上，生产者生产出的queue只放在其中一个RabbitMQ实例上，其他实例上存放的是queue元数据（元数据存放一些RabbitMQ的配置信息，可以通过元数据找到拥有实际数据的queue），如果消费者拉取的正好是放有queue实际数据的RabbitMQ，就会直接拉取到，如果拉取的是另外的RabbitMQ，会通过queue元数据定位到存放queue实际数据的RabbitMQ，从那里拉取数据再发给消费者。
显然这种模式也不能保证高可用，如果放有实际数据的RabbitMQ宕机，别的RabbitMQ也找不到queue实际数据了，只有等这台RabbitMQ恢复才能拉取数据，如果没有开启消息持久化，甚至数据也会没了，这种模式仅仅被用来提高吞吐量
和普通集群模式类似，也是多台RabbitMQ实例。与之不同的地方在于，每台RabbitMQ实例上都有完整的queue镜像，首先生产者会生产出queue放到一台RabbitMQ上，其他的RabbitMQ会同步这台RabbitMQ上的queue，保证每台RabbitMQ上的queue都是一样的，都包含着实际数据，如果一台RabbitMQ宕机，没有关系，别的RabbitMQ上也有queue，保证了RabbitMQ的可用性，开启这个模式只需在控制台添加镜像集群模式策略即可
优点：一台RabbitMQ宕机，消费者还可以去别的RabbitMQ上拉消息
缺点：
①性能开销大，因为消息需要同步，对网络的压力比较大
②没有扩展性，如果一个queue负载很大，如果添加RabbitMQ，这个RabbitMQ上也会同步queue的全部数据，也会有很大的负载，不能线性地扩展queue
在Kafka 0.8之前是没有HA机制的，如果哪个broker宕机了，那么这个broker上的partition也就没有了，没有高可用
例如，生产者生产出的topic被分成3个partition，每个partition相当于topic的1/3，被分给3个broker，如果第二个broker宕机了，那么这1/3的partition也就没了
Kafka 0.8之后，就出现了HA机制，是通过replica副本来完成的，对于每个partition，会生成多个replica副本，并分给所有的broker，对于同一个partition的多个replica，会选举出一个leader，其余的为follower，生产和消费都在leader上完成，在写的时候，leader会把数据同步给其余的follower，读的时候只需要在leader上读即可
为什么只能在leader上读写呢？因为假如你还在follower上面读写的话，就要考虑数据一致性的问题了，可能会出现数据重复，丢失，混乱的问题，Kafka 会均匀地将一个 partition 的所有replica分布在不同的broker上，这样才可以提高容错性。
这样以来，有高可用性了，如果一个broker宕机，其他broker上面都有这个partition的replica副本，如果宕机的是某个partition的leader，此时会从其他的follower中选举出一个leader，读写这个leader即可，这就是高可用。
生产的时候，生产者就往leader中写数据，然后leader就把这个数据放到本地磁盘中，其他follower会从leader中pull数据，当所有follower都同步完成之后，就会发送ack给leader，leader确认收到ack之后就会返回给生产者成功写入的消息
消费的时候，只会从leader上读数据，消费者只能在这个消息被follower返回ack之后才能读到
