大家好,我是 Tom哥~
马上要开启国庆小长假了,祝大家节日快乐,吃喝玩乐走起~
为了便于大家查找问题,了解全貌,整理个目录,我们可以快速全局了解关于消息队列,面试官一般会问哪些问题。
本篇文章的目录:
消息队列的应用场景?
答案:1、异步处理 2、流量削峰填谷 3、应用解耦 4、消息通讯
电源适配器
也是这个原理。常用的消息框架有哪些?
答案:ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaQ,RocketMQ、Pulsar 等
MQ技术选型?
答案:对比了 Kafka、RocketMQ 、Pulsar 三个框架,时耗、吞吐量、可靠性、事务、副本同步策略、多租户、动态扩容、故障恢复等评估指标。详细内容,参考 为什么放弃Kafka,选择Pulsar?
消息模型有哪些?
答案:1、点对点模式 2、发布/订阅模式
如何保证 MQ 消息不丢失?
答案:在了解消息中间件的运作模式后,主要从三个方面来考虑这个问题:
如何解决消息的重复消费?
答案:生产端为了保证消息发送成功,可能会重复推送(直到收到成功ACK),会产生重复消息。但是一个成熟的MQ Server框架一般会想办法解决,避免存储重复消息(比如:空间换时间,存储已处理过的message_id),给生产端提供一个幂等性的发送消息接口。
但是消费端却无法根本解决这个问题,在高并发标准要求下,拉取消息+业务处理+提交消费位移需要做事务处理,另外消费端服务可能宕机,很可能会拉取到重复消息。
所以,只能业务端自己做控制,对于已经消费成功的消息,本地数据库表或Redis缓存业务标识,每次处理前先进行校验,保证幂等。
如何保证 MQ消息是有序的?
答案:有些业务有上下文要求,比如:电商行业的下单、付款、发货、确认收货,每个环节都会发送消息。而消费端拉取并消费消息时,也是希望按正常的状态机流程进行。所以对消息就有了顺序要求。解决思路:
partition
,单线程消费。比如Kafka
就提供了一个接口扩展org.apache.kafka.clients.Partitioner
,方便开发人员按照自己的业务场景来定制路由规则。消息堆积如何处理?
答案:主要是消息的消费速度跟不上生产速度,从而导致消息堆积。解决思路:
如何保证数据一致性问题?
答案:为了解耦,引入异步消息机制。先进行本地数据库操作,处理成功后,再发送MQ消息,由消费端进行后续操作。比如:电商订单下单成功后,要通知扣减库存。
这两者一定要保证事务操作,否则就会出现数据不一致问题。这时候,我们就需要引入事务消息
来解决这个问题。
另外,在消费环节,也可能出现数据不一致情况。我们可以采用最终一致性
原则,增加重试机制。
事务消息是如何实现?
答案:
MQ框架 如何实现高吞吐量?
答案:
Kafka 为什么不支持读写分离?
答案:我们知道,生产端写入消息、消费端拉取消息都是与leader 副本交互的,并没有像mysql数据库那样,master负责写,slave负责读。
这种设计主要是从两个方面考虑:
消费位移
来控制消息拉取进度,多个副本间要维护同一个消费位移的一致性。如果引入分布式锁,保证并发安全,非常耗费性能。综上考虑,读写操作都是针对 leader 副本进行的,而 follower 副本主要是用于数据的备份。
MQ框架如何做到高可用性?
答案:以Kafka框架为例,其他的MQ框架原理类似。
Kafka 由多个 broker 组成,每个 broker 是一个节点。你创建一个 topic,这个 topic 可以划分为多个 partition,每个 partition 存放在不同的 broker 上,每个 partition 存放一部分数据,每个 partition 有多个 replica 副本。
写的时候,leader 会负责把数据同步到所有 follower 上去,读的时候就直接读 leader 上的数据即可。
如果某个 broker 宕机了,没事儿,那个 broker 上面的 partition 在其他机器上都有副本,此时会从 follower 中重新选举一个新的 leader 出来,大家继续读写那个新的 leader 即可。这就是所谓的高可用性。
更多内容,可以参考 关于消息队列,面试官一般都会问哪些?
关于Kafka,面试官一般喜欢考察哪些问题?
答案:
关于我:前阿里P7技术专家,出过专利,竞赛拿过奖,CSDN博客专家,负责过电商交易、社区生鲜、互联网金融等业务,多年团队管理经验。