面试题
如何保障音讯队列的高可用？
面试官心理剖析
如果有人问到你 MQ 的常识，高可用是必问的 。上一讲提到，MQ 会导致 零碎可用性升高。所以只有你用了 MQ，接下来问的一些要点必定就是围绕着 MQ 的那些毛病怎么来解决了。
要是你傻乎乎的就干用了一个 MQ，各种问题素来没思考过，那你就杯具了，面试官对你的感觉就是，只会简略应用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的一般小弟还对付，要是做薪资 20k+ 的高工，那就惨了，让你设计个零碎，外面必定一堆坑，出了事变公司受损失，团队一起背锅。
面试题分析
这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保障？ActiveMQ 的高可用性怎么保障？一个面试官要是这么问就显得很没程度，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。
所以有程度的面试官，问的是 MQ 的高可用性怎么保障？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的了解。
RabbitMQ 的高可用性
RabbitMQ 是比拟有代表性的，因为是 基于主从（非分布式）做高可用性的，咱们就以 RabbitMQ 为例子解说第一种 MQ 的高可用性怎么实现。
RabbitMQ 有三种模式：单机模式、一般集群模式、镜像集群模式。
单机模式
单机模式，就是 Demo 级别的，个别就是你本地启动了玩玩儿的 ????，没人生产用单机模式。
一般集群模式（无高可用性）
一般集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你 创立的 queue，只会放在一个 RabbitMQ 实例上 ，然而每个实例都同步 queue 的元数据（元数据能够认为是 queue 的一些配置信息，通过元数据，能够找到 queue 所在实例）。你生产的时候，实际上如果连贯到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过去
这种形式的确很麻烦，也不怎么好，没做到所谓的分布式 ，就是个一般集群。因为这导致你要么消费者每次随机连贯一个实例而后拉取数据，要么固定连贯那个 queue 所在实例生产数据，前者有 数据拉取的开销 ，后者导致 单实例性能瓶颈。
而且如果那个放 queue 的实例宕机了，会导致接下来其余实例就无奈从那个实例拉取，如果你 开启了音讯长久化 ，让 RabbitMQ 落地存储音讯的话， 音讯不肯定会丢，得等这个实例复原了，而后才能够持续从这个 queue 拉取数据。
所以这个事儿就比拟难堪了，这就 没有什么所谓的高可用性 ， 这计划次要是进步吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。
镜像集群模式（高可用性）
这种模式，才是所谓的 RabbitMQ 的高可用模式。跟一般集群模式不一样的是，在镜像集群模式下，你创立的 queue，无论元数据还是 queue 里的音讯都会 存在于多个实例上 ，就是说，每个 RabbitMQ 节点都有这个 queue 的一个 残缺镜像 ，蕴含 queue 的全副数据的意思。而后每次你写音讯到 queue 的时候，都会主动把 音讯同步 到多个实例的 queue 上。
那么 如何开启这个镜像集群模式 呢？其实很简略，RabbitMQ 有很好的治理控制台，就是在后盾新增一个策略，这个策略是 镜像集群模式的策略，指定的时候是能够要求数据同步到所有节点的，也能够要求同步到指定数量的节点，再次创立 queue 的时候，利用这个策略，就会主动将数据同步到其余的节点下来了。
这样的话，益处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还蕴含了这个 queue 的残缺数据，别的 consumer 都能够到其它节点下来生产数据。害处在于，第一，这个性能开销也太大了吧，音讯须要同步到所有机器上，导致网络带宽压力和耗费很重！第二，这么玩儿，不是分布式的，就 没有扩展性可言 了，如果某个 queue 负载很重，你加机器，新增的机器也蕴含了这个 queue 的所有数据，并 没有方法线性扩大 你的 queue。你想，如果这个 queue 的数据量很大，大到这个机器上的容量无奈包容了，此时该怎么办呢？
Kafka 的高可用性
Kafka 一个最根本的架构意识：由多个 broker 组成，每个 broker 是一个节点；你创立一个 topic，这个 topic 能够划分为多个 partition，每个 partition 能够存在于不同的 broker 上，每个 partition 就放一部分数据。
这就是 人造的分布式音讯队列 ，就是说一个 topic 的数据，是 扩散放在多个机器上的，每个机器就放一部分数据。
实际上 RabbitMQ 之类的，并不是分布式音讯队列，它就是传统的音讯队列，只不过提供了一些集群、HA(High Availability, 高可用性) 的机制而已，因为无论怎么玩儿，RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的残缺数据。
Kafka 0.8 以前，是没有 HA 机制的，就是任何一个 broker 宕机了，那个 broker 上的 partition 就废了，没法写也没法读，没有什么高可用性可言。
比如说，咱们假如创立了一个 topic，指定其 partition 数量是 3 个，别离在三台机器上。然而，如果第二台机器宕机了，会导致这个 topic 的 1/3 的数据就丢了，因而这个是做不到高可用的。
Kafka 0.8 当前，提供了 HA 机制，就是 replica（复制品）正本机制。每个 partition 的数据都会同步到其它机器上，造成本人的多个 replica 正本。所有 replica 会选举一个 leader 进去，那么生产和生产都跟这个 leader 打交道，而后其余 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 下来，读的时候就间接读 leader 上的数据即可。只能读写 leader？很简略，要是你能够随便读写每个 follower，那么就要 care 数据一致性的问题 ，零碎复杂度太高，很容易出问题。Kafka 会平均地将一个 partition 的所有 replica 散布在不同的机器上，这样才能够进步容错性。
这么搞，就有所谓的 高可用性 了，因为如果某个 broker 宕机了，没事儿，那个 broker 下面的 partition 在其余机器上都有正本的。如果这个宕机的 broker 下面有某个 partition 的 leader，那么此时会从 follower 中 从新选举 一个新的 leader 进去，大家持续读写那个新的 leader 即可。这就有所谓的高可用性了。
写数据 的时候，生产者就写 leader，而后 leader 将数据落地写本地磁盘，接着其余 follower 本人被动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写胜利的音讯给生产者。（当然，这只是其中一种模式，还能够适当调整这个行为）
生产 的时候，只会从 leader 去读，然而只有当一个音讯曾经被所有 follower 都同步胜利返回 ack 的时候，这个音讯才会被消费者读到。
看到这里，置信你大抵明确了 Kafka 是如何保障高可用机制的了，对吧？不至于无所不知，现场还能给面试官画画图。要是遇上面试官的确是 Kafka 高手，深挖了问，那你只能说不好意思，太深刻的你没钻研过。
分享到此，喜爱的能够点赞珍藏加关注！
学习更多 Java 技术能够退出我的十年 Java 学习裙：3907814