面试题——如何保证消息队列的高可用

面试题

如何保证消息队列的高可用？

面试官心理分析

围绕着MQ进行面试，肯定会聊到高可用相关的话题，因为引入了MQ中间件导致了系统的可用性降低。MQ所带来的一些坑，在实际项目中是如何解决的。
如果回答只是单纯的在MQ，并没有考虑过各种有可能出现的问题，那面试的印象分就会迅速降低。

面试题剖析

是让你结合项目说一说在实际的生产环境中如何实现MQ的高可用性。

Kafka的高可用性

Kafka的一个最基本的架构认知：Kafka由躲个broker组成，每个broker就是一个节点，当创建一个topic的时候，会划分为多个partition，每个partition可以存在于不同的broker上，每个partition存放一部分数据。
这就是天然的分布式系统，一个topic的数据会分散在不同的机器上面。与此相比，RabbitMQ之类并不是真正意义上的分布式系统，因为没有做到消息分片，每台机器上都存放着完整的数据，只是提供了一些高可用的机制。
Kafka从0.8版本之后，提供了HA机制，就是replica机制。每个partition的数据都会同步到其他机器上，形成多个replica副本。所有的replica会投票选举出来一个leader，其他节点都会跟这台leader打交道，进行数据的同步，所有的读写请求也是走leader。
这个会引申出一个问题为什么读写请求只走Leader？因为如果可以随意访问follower，就要处理一致性问题，系统的复杂性将会成倍增长，因此follower只参与到备份操作。
这样一来，就实现了所谓的高可用性，如果某台leader宕机了，就会从副本当中选举一个出来，其他节点继续跟这个新的leader节点进行同步，此时集群仍是可用的。
写数据的时候，生产者将数据发送给leader节点，leader节点将数据落地到磁盘，接着其他的follwer主动从leader节点中pull数据到自己本地，并发送ack给leader节点。当所有的follower节点都将数据同步完成好之后，leader节点才返回给生产者成功的消息（这是一种策略）。
读数据的时候，只会从leader上面去读，但是只有所有的follower节点同步操作完成之后，这个时候数据才会被读到。