rabbitMQ有三种模式：单机模式、普通集群、镜像集群
1）单击模式
就是启动本地的Demo
2）普通集群模式
就是多台机器上启动多个rabbitMQ实例，每个机器启动一个实例，每个机器都有queue的元数据（配置信息这种的） ，queue放在其中一个实例上。要消费的时候，如果连接到只有queue元数据的机器，这个机器上的实例，会从queue在的实例上拉取数据过来，前者会有拉取数据的开销，后者会有性能瓶颈，且还会有queue所在实例挂掉的风险。
rabbitMQ普通集群模式
3）镜像集群模式
镜像集群模式才是rabbitMQ的高可用模式，跟普通集群不一样的是创建的queue，无论是元数据还是queue里的消息都会存在多个实例上，，每次吧消息写到queue上的时候，都会自动把消息在多个实例上进行同步。这样的好处就是，任何一个机器宕机了，别的机器还能一样用。弊端在于1.性能开销大，消息同步的所有机器，导致带宽压力，2.没有扩展可言，如果某一个queue负载就很重，加机器也包含这个queue的所有数据，没有办法线性扩展。
2.kafka的高可用镜像集群模式
如何开启这个镜像集群模式呢？
RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
Kafka这个最基本的架构：由每个broker组成，每个broker是一个节点；你创建一个topic，topic可以划分为多个partition，partition可以存在于不同的broker上，每个partition就可以存在放一部分数据。注：topic 中的数据被拆分到多个机器上，即 partition
这就是一个天然的数据主题，就是说的数据，是可以分配多个数据的机器就可以了。
Kafka 0.8 以前，是没有 HA 机制（高可用：replica 副本机制 + 消息同步 + leader 选举）的，就是任何一个 broker 停机没有机器了，那个 broker 上的分区就废了，没法写也读不出来，没什么高可用性可言。 如果我们假设创建了一个话题，指定其分区数量是3个，但是分别在三台机器上。如果第二台机器停机了，会导致话题的1/3的数据就丢了，所以这是做不到高可用的。
Kafka 0.8以后，提供HA机制，就是副本（复制品）机制follower。每个分区的数据单元同步到机器上，形成自己的多个副本副本。所有副本会议副本一个leader出来，这样生产和消费都跟这个打交道，然后其他复制品就是追随者。写的时候， leader会负责把数据同步到上去，读的时候就直接读leader的数据了。
这么一来，这时候的高效率搞起了，如果这个leader的分区停机了，副本follower 上的数据和leader一样。kafka就选举一个副本follower为leader，无论是生产者还是消费者都和这个新选举出来的leader做数据交互。这样就有了这样的高可用性了。
kafka高可用
读写操作
- 只能对 leader 进行读写！其他 follower 主动从 leader 处 pull 数据（保证一致性）
- 写，一个消息只能等所有的 follower 都同步成功，都成功返回 ack 给 leader ，才会返回写成功的消息给生产者！
- 读，一个消息只能等所有的 follower 都同步成功，都成功返回 ack 给 leader ，才能被读取！
