面试题
如何保证消息队列的高可用?
面试官心理分析
围绕着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节点同步操作完成之后,这个时候数据才会被读到。