本文原文链接
尼恩说在前面
在45岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团、蚂蚁、得物的面试资格，遇到很多很重要的相关面试题：
问题5：如何根据应用场景选择合适的消息中间件?
最近有小伙伴面试招行， 问到了相关的面试题。
小伙伴没有系统的去梳理和总结，所以支支吾吾的说了几句，面试官不满意，面试挂了。
所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V175版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取
招商银行的高阶Java后端面试真题
被狠狠拷打了，问的人都懵了。项目场景题太难了，不好好准备，真的答不出!
尼恩将给出全部答案：
1.如何让系统抗住双十一的预约抢购活动?
2.如何从零搭建10万级QPS大流量、高并发优惠券系统?
3.百万级别数据的 Excel 如何快速导入到数据
4.如何设计一个支持万亿GB网盘实现秒传与限速的系统?
5.如何根据应用场景选择合适的消息中间件?
本文
6.如何提升 RocketMQ 顺序消费性能?
即将发布。
7.使用分布式调度框架该考虑哪些问题?
即将发布。
9.如何让系统抗住双十一的预约抢购活动?
10.问 ：如何解决高并发下的库存抢购超卖少买？
即将发布。
11.为什么高并发下数据写入不推荐关系数据？
12.如果让你设计一个分布式链路跟踪系统?
即将发布。
前几天 尼恩给一个 小伙伴改造过一个 100wtps 链路跟踪平台简历， 非常NB， 牛到暴表。
本文目录
招行面试：如何根据应用场景选择合适的消息中间件?
分布式、微服务、高并发架构中，消息队列（Message Queue，简称MQ）扮演着至关重要的角色。
消息队列用于实现系统间的异步通信、解耦、削峰填谷等功能。
目前常见的MQ实现包括RabbitMQ、RocketMQ和Kafka。
RocketMQ、Kafka、RabbitMQ如何选择？
接下来，尼恩给大家 对比RocketMQ和RabbitMQ和Kafka，帮助大家在技术选型时做出最佳的技术选型。
三大MQ的简单对比
| 特性 | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|
| 公司/社区 | Rabbit | 阿里 | Apache |
| 开发语言 | Erlang | Java | Scala & Java |
| 协议支持 | AMQP，XMPP，SMTP，STOMP | 自定义协议 | 自定义协议 |
| 可用性 | 高 | 高 | 高 |
| 单机吞吐量 | 一般 | 高 | 非常高 |
| 消息延迟 | 微秒级 | 毫秒级 | 毫秒以内 |
| 消息可靠性 | 高 | 高 | 一般 |
第一大mq：RabbitMQ
RabbitMQ是由Pivotal开发的开源消息队列系统，基于Erlang语言开发，采用 AMQP（Advanced Message Queuing Protocol）协议。
以下是RabbitMQ的一些主要特点：
RabbitMQ优点
- 高可靠性：RabbitMQ支持消息持久化、确认机制和死信队列等功能，确保消息不会丢失。
- 灵活的路由机制：支持多种交换机类型（如直连交换机、主题交换机、扇出交换机等），能够灵活地根据业务需求路由消息。
- 丰富的插件：RabbitMQ拥有丰富的插件支持，如管理界面插件、监控插件等，方便运维和管理。
- 低延迟：在低延迟消息传递场景中表现出色，适用于实时性要求较高的业务场景。
RabbitMQ缺点
- 性能瓶颈：在高并发和大吞吐量场景下，RabbitMQ可能会遇到性能瓶颈，需要进行性能调优。
- 扩展性：虽然支持集群模式，但在大规模集群下的扩展性不如Kafka和RocketMQ。
RabbitMQ使用场景：
适用于中小型企业的一般消息队列需求，如异步任务处理、系统解耦、消息通知等场景 。
第二大mq：Kafka
Apache Kafka是一个分布式流处理平台，最初由LinkedIn开发，并于2011年开源。
Kafka的设计初衷是用于高吞吐量、低延迟的数据流处理和实时数据管道。
Kafka的核心组件包括生产者、消费者、主题和分区。
Kafka优点：
- 高吞吐量：Kafka能够处理每秒数百万条消息，适合大规模数据流处理。
- 水平扩展性：通过分区机制，Kafka可以轻松扩展，支持大规模分布式部署。
- 持久化存储：Kafka将消息持久化到磁盘，确保数据的可靠性和持久性。
- 高可用性：通过复制机制，Kafka能够在节点故障时继续提供服务。
- 低延迟：Kafka设计为低延迟系统，适合实时数据处理。
Kafka缺点：
- 复杂性：Kafka的部署和管理相对复杂，需要专业知识和经验。
- 资源占用：Kafka对硬件资源要求较高，特别是磁盘和网络带宽。
- 延迟一致性：Kafka采用最终一致性模型，可能导致短暂的不一致。
Kafka使用场景：
- 实时数据处理：需要处理高吞吐量、低延迟的数据流，如实时日志分析、实时监控和实时推荐系统。
- 大数据管道：构建数据管道，将数据从不同来源高效传输到数据湖或数据仓库。
- 事件驱动架构：实现事件驱动的微服务架构，支持事件的发布和订阅。
- 日志聚合：集中收集和处理分布式系统的日志数据，进行统一分析和监控。
第三大mq：RocketMQ
RocketMQ是阿里巴巴开源的一款分布式消息队列系统，采用Java语言开发，具备高性能、高可靠性和高可用性的特点。2016年捐赠给Apache基金会。
RocketMQ的设计目标是高可靠性、高性能和高可用性，支持分布式事务和顺序消息等高级特性。
RocketMQ的核心组件包括生产者、消费者、主题和队列。
以下是RocketMQ的一些主要特点：
RocketMQ优点
- 高吞吐量：RocketMQ设计之初就考虑到了高吞吐量的需求，适用于大规模的消息传输场景。
- 分布式架构：天然支持分布式架构，易于横向扩展，适用于大规模集群部署。
- 消息顺序：支持严格的消息顺序，满足对消息顺序性有严格要求的业务场景。
- 灵活的消费模式：支持多种消费模式，包括广播消费和集群消费。
- 丰富的功能：支持定时消息、延迟消息、死信队列和批量消息等高级功能，满足复杂业务需求。
RocketMQ缺点
- 社区活跃度：是国产的消息中间件，有活跃的国内社区支持，相关的技术文档和案例较为丰富，同时也得到了阿里巴巴等企业的技术支持。
- 学习成本：相比RabbitMQ，RocketMQ的配置和使用相对复杂，学习成本较高。
- 生态系统：虽然正在快速发展，但RocketMQ的生态系统和社区支持相比RabbitMQ和Kafka还有一定差距。
RocketMQ使用场景：
- 金融交易系统：需要高可靠性和顺序消息处理的金融交易系统。
- 电商平台：处理高并发订单和支付消息，确保消息的可靠传递和顺序处理。
- 分布式事务：支持分布式事务的业务场景，如跨服务的事务管理。
- 消息通知系统：实现高可靠性的消息通知和广播，如短信、邮件通知系统。
为什么阿里会自研RocketMQ？
（1）Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够
（2）阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高。
kafka针对海量数据，但是对数据的正确度要求不是十分严格。
而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适
（3）当业务成长到一定规模，采用开源方案的技术成本会变高.
开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容都可能是问题；运维角度，Kafka使用 scala 编写，而阿里是java系。Kafka 的后续维护是个问题。
（4）阿里在团队、成本、资源投入等方面约束性条件几乎没有.
RocketMQ、Kafka、RabbitMQ的全面对比和PK
RocketMQ、Kafka、RabbitMQ 都是常用的消息中间件 ，可从性能、功能、可靠性、运维复杂度等方面进行全面PK：
三大mq 性能PK
- RocketMQ：
10Wtps 级别。
采用分布式架构，能支持高并发和低延迟的消息处理，在大规模数据处理场景下表现稳定，消息发送和消费的性能较高，适合对性能要求较高的分布式系统。
- Kafka：
10Wtps 级别。
以高吞吐量著称，擅长处理大规模的消息流数据，适用于对实时性要求高、数据量大的场景，如日志收集、实时数据处理等。
- RabbitMQ：
1Wtps 级别。
性能相对较弱，在处理大量消息时可能会出现性能瓶颈，但在小规模场景下表现良好，能满足一般的消息队列需求。
三大mq 功能PK
- RocketMQ：
支持事务消息、顺序消息、广播消息等高级特性，能满足一些对消息处理有严格要求的业务场景，如电商订单处理等。
- Kafka：
具有强大的分区、副本和多副本机制，能保证数据的高可用性和可靠性，同时支持消息的批量处理和压缩，提高了数据传输效率。
- RabbitMQ：
支持多种消息队列模式，如点对点、发布订阅、路由等，提供了丰富的插件生态，可通过插件扩展功能，如实现消息的延迟发送等。
三大mq 可靠性 PK
- RocketMQ：
- 采用分布式架构和多副本机制，保证了数据的可靠性和高可用性，支持消息的持久化和故障转移，能在节点故障时快速恢复消息处理。
- Kafka：
- 通过多副本机制和分布式存储，确保数据的可靠性和容错性，能自动进行副本的选举和故障转移，保证消息不丢失。
- RabbitMQ：
- 支持消息的持久化和镜像队列等机制，可保证消息在节点故障时不丢失，但在大规模集群环境下，维护其可靠性的复杂度相对较高。
三大mq 运维 PK
- RocketMQ：
运维相对简单，提供了可视化的管理控制台，方便进行集群管理、消息监控等操作，对运维人员的技术要求相对较低。
- Kafka：
集群部署和运维相对复杂，需要对分布式系统和存储有一定的了解，涉及到多个组件的配置和管理，但有一些开源的运维工具可降低运维难度。
- RabbitMQ：
运维复杂度适中，提供了管理界面，但在集群扩展和性能调优方面需要一定的技术经验，对运维人员的要求较高。
三大mq 社区生态 PK
- RocketMQ：
是国产的消息中间件，有活跃的国内社区支持，相关的技术文档和案例较为丰富，同时也得到了阿里巴巴等企业的技术支持。
- Kafka：
拥有庞大的开源社区，有丰富的文档、插件和周边工具，生态系统成熟，在大数据领域有广泛的应用和支持。
- RabbitMQ：
社区活跃度高，有大量的开源插件和工具可供使用，商业支持也较为完善，能为企业提供专业的技术服务。
三大mq 支持的队列数 PK
大型业务场景， Kafka 单机超过64个队列/分区，消息发送性能降低严重，需要进行深度定制和改造 ，京东就改造过；
大型业务场景， RocketMQ 单机支持最高5万个队列，而且 性能稳定
RabbitMQ 是企业级的mq，大型的业务场景很少人使用。
三大mq 适用场景 PK
- RocketMQ：适用于对消息可靠性、顺序性要求高，以及有分布式事务需求的场景，如金融交易、电商订单处理、分布式事务协调等。
- Kafka：适合用于大数据处理、实时数据流式处理、日志收集与分析等对吞吐量要求高、实时性强、消息可靠性要求低的场景。
- RabbitMQ：适用于中小型企业的一般消息队列需求，如异步任务处理、系统解耦、消息通知等场景，尤其适合对消息处理逻辑复杂、需要灵活配置的情况。
三大mq 如何选择？
尼恩建议大家，围绕RocketMQ 和 Kafka做选型：
- 消息高可靠场景、队列数量庞大的场景，选择 RocketMQ
- 消息低可靠场景、队列数量较少的场景，选择 Kafka
说在最后：有问题找老架构取经
只要按照上面的 尼恩团队梳理的 方案去作答， 你的答案不是 100分，而是 120分。 面试官一定是 心满意足， 五体投地。
按照尼恩的梳理，进行 深度回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。
很多小伙伴刷完后， 吊打面试官， 大厂横着走。
在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。
另外，如果没有面试机会， 可以找尼恩来改简历、做帮扶。前段时间，刚指导一个小伙 暴涨200%（涨2倍），29岁/7年/双非一本 ， 从13K一次涨到 37K ，逆天改命。
狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。
尼恩技术圣经系列PDF
- 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
- 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
- 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
- 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
- 《大数据HBase学习圣经：一本书实现HBase学习自由》
- 《大数据Flink学习圣经：一本书实现大数据Flink自由》
- 《响应式圣经：10W字，实现Spring响应式编程自由》
- 《Go学习圣经：Go语言实现高并发CRUD业务开发》
……完整版尼恩技术圣经PDF集群，请找尼恩领取
