消息队列

Author: xbox1994

MD/分布式-消息队列.md

@@ -40,3 +40,22 @@ RabbitMQ 如果丢失了数据，主要是因为你消费的时候，刚消费
 
 在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择一个队列，同一个订单号获取到的肯定是同一个队列。
 
+## 集群模式
+### 普通集群模式
+在多台机器上启动多个 RabbitMQ 实例。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。
+
+缺点是不能保证高可用、还有拉去数据的开销、以及单实例的性能瓶颈，所以这个方案是为了提高吞吐量的
+
+### 镜像集群模式
+每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。
+
+缺点是即时满足了高可用，但因为同步数据量太重导致难以扩展节点，也没有在架构上实现负载均衡，可以参考Redis的集群模式进行优化。
+
+### Kafka 的高可用性
+Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据
+
+每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。
+
+如果某个 broker 宕机了，没事儿，那个 broker上面的 partition 在其他机器上都有副本的，如果这上面有某个 partition 的 leader，那么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。
+
+![](https://github.com/xbox1994/2018-Java-Interview/raw/master/images/kafka集群.png)