RocketMQ面试题八股文.pdfVIP

图⽂详解 RocketMQ ⾯试⾼频题，这次吊打⾯试官，我觉得稳了（⼿动 dog）。整理：楼仔，作者：三分 恶，戳原⽂链接。 基础 1.为什么要使⽤消息队列呢？ 消息队列主要有三⼤⽤途，我们拿⼀个电商系统的下单举例： 解耦：引⼊消息队列之前，下单完成之后，需要订单服务去调⽤库存服务减库存，调⽤营销服务加营销数 据……引⼊消息队列之后，可以把订单完成的消息丢进队列⾥，下游服务⾃⼰去调⽤就⾏了，这样就完成了订 单服务和其它服务的解耦合。 异步：订单⽀付之后，我们要扣减库存、增加积分、发送消息等等，这样⼀来这个链路就⻓了，链路⼀⻓， 响应时间就变⻓了。引⼊消息队列，除了更新订单状态 ，其它的都可以异步去做，这样⼀来就来，就能降低 响应时间。 削峰：消息队列合⼀⽤来削峰，例如秒杀系统，平时流量很低，但是要做秒杀活动，秒杀的时候流量疯狂怼 进来，我们的服务器，Redis，MySQL各⾃的承受能⼒都不⼀样，直接全部流量照单全收肯定有问题啊，严重 点可能直接打挂了。 我们可以把请求扔到队列⾥⾯，只放出我们服务能处理的流量，这样就能抗住短时间的⼤流量了。 解耦、异步、削峰，是消息队列最主要的三⼤作⽤。 2.为什么要选择RocketMQ? 市场上⼏⼤消息队列对⽐如下： 总结⼀下： 选择中间件的可以从这些维度来考虑：可靠性，性能，功能，可运维⾏，可拓展性，社区活跃度。⽬前常⽤的⼏个 中间件，ActiveMQ作为“⽼古董” ，市⾯上⽤的已经不多，其它⼏种： RabbitMQ ： 优点：轻量，迅捷，容易部署和使⽤，拥有灵活的路由配置 缺点：性能和吞吐量不太理想，不易进⾏⼆次开发 RocketMQ ： 优点：性能好，⾼吞吐量，稳定可靠，有活跃的中⽂社区 缺点：兼容性上不是太好 Kafka ： 优点：拥有强⼤的性能及吞吐量，兼容性很好 缺点：由于“攒⼀波再处理”导致延迟⽐较⾼ 我们的系统是⾯向⽤户的C端系统，具有⼀定的并发量，对性能也有⽐较⾼的要求，所以选择了低延迟、吞吐量⽐ 较⾼，可⽤性⽐较好的RocketMQ。 3.RocketMQ有什么优缺点？ RocketMQ优点： 单机吞吐量：⼗万级 可⽤性：⾮常⾼，分布式架构 消息可靠性：经过参数优化配置，消息可以做到0丢失 功能⽀持：MQ功能较为完善，还是分布式的，扩展性好 ⽀持10亿级别的消息堆积，不会因为堆积导致性能下降 源码是Java ，⽅便结合公司⾃⼰的业务⼆次开发 天⽣为⾦融互联⽹领域⽽⽣，对于可靠性要求很⾼的场景，尤其是电商⾥⾯的订单扣款，以及业务削峰，在 ⼤量交易涌⼊时，后端可能⽆法及时处理的情况 RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿⾥双11已经经历了多次考验，如果你的业务有上述 并发场景，建议可以选择RocketMQ RocketMQ缺点： ⽀持的客户端语⾔不多，⽬前是Java 及c++，其中c++不成熟 没有在 MQ核⼼中去实现JMS 等接⼝，有些系统要迁移需要修改⼤量代码 4.消息队列有哪些消息模型？ 消息队列有两种模型：队列模型和发布/订阅模型。 队列模型 这是最初的⼀种消息队列模型，对应着消息队列“发-存-收”的模型。⽣产者往某个队列⾥⾯发送消息，⼀个队列可 以存储多个⽣产者的消息，⼀个队列也可以有多个消费者，但是消费者之间是竞争关系，也就是说每条消息只能被 ⼀个消费者消费。 发布/订阅模型 如果需要将⼀份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型⽆法满⾜ 这个需求。解决的⽅式就是发布/订阅模型。 在发布 - 订阅模型中，消息的发送⽅称为发布者（Publisher），消息的接收⽅称为订阅者（Subscriber），服务 端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主 题” 。“订阅”在这⾥既是⼀个动作，同时还可以认为是主题在消费时的⼀个逻辑副本，每份订阅中，订阅者都可以接 收到主题的所有消息。 它和 “队列模式” 的异同：⽣产者就是发布者，队列就是主题，消费者就是订阅者，⽆本质区别。唯⼀的不同点在 于：⼀份消息数据是否可以被多次消费。 5.那RocketMQ的消息模型呢？ RocketMQ使⽤的消息模型是标准的发布-订阅模型，在RocketMQ的术语表中，⽣产者、消费者和主题，与发布- 订