前言

第一次被问到"消息中间件如何选型"这个问题，大概是在2018年。当时的我对于消息中间件的认知仅停留在使用层面，不知所以然，自然也就回答不上来。

为了避免小伙伴们遇到同样的问题，在此分享一下我对这个问题的见解，欢迎大家交流。

选型的目的

众所周知，目前市面上成熟的消息中间件均能达到系统解耦、流量削峰、异步处理等效果。虽然这些中间件在功能上有所重叠，但是在设计和实现上都有各自的优势。具体使用哪个中间件还是要根据实际的情况来选择。

在选型时我认为需要从以下几点出发：

是否满足业务需求：不同的业务场景对消息中间件有不同的需求。例如，有些业务可能需要高吞吐量和低延迟的消息传递，而有些业务可能更关注消息传递的可靠性。
中间件是否稳定可靠：除满足基本的业务需求外，还要考虑中间件自身是否稳定可靠，避免中间件自身的问题造成系统的不稳定。
是否会增加开发运维成本：各消息中间件的实现不同，我们需要关注中间件是否容易集成、有没有提供完善的技术文档来解决问题。避免对开发人员造成过大的学习成本和后期的维护成本。

所以简单来说，消息中间件的选型目的主要是在满足业务需求的同时，还要保证系统的稳定不受其影响，并且力求最低的开发运维成本。

这里以RabbitMQ、Kafka、RocketMQ为选型竞品，结合选型的目的，通过各中间件的架构模型了解下一下各竞品的特征及优势，以便对"消息中间件如何选型"这个问题进行回答。

（默认各位看官对消息中间件有基本的了解）

RabbitMQ以高性能、健壮以及可伸缩性出名的Erlang语言编写，在扩展或删除集群节点时只需要同步erlang信息即可，同时镜像集群模式可以确保高可用。
RabbitMQ有灵活的消息路由配置 ，可以实现不同的消息路由需求。如下图
RabbitMQ在数据可靠性的问题上做了很大的努力，它保证在这里数据是非常可靠的。

通过Kafka的架构模型，可以看出Kafka是一个分布式架构，Zookeeper作为Kafka集群的协调者，负责维护和管理Kafka集群的状态，确保集群的可用性和一致性。
Kafka由Scala和Java编写，通过零拷贝、pagecahe技术以及分区的设计提高了系统的吞吐量。

通过RocketMQ的架构模型，可以看出RocketMQ和Kafka的架构相似，不同的是，RocketMQ可以处理延迟消息、顺序消息、分布式事务等场景。
RocketMQ是阿里出品的，社区非常活跃，已经受到各企业的广泛应用，可用性和可靠性也得到广泛认可。

通过一个案例进行选型说明，案例如下：

一个电商平台需要实时收集订单信息、用户行为数据以及日志数据，并进行实时分析和处理。同时，平台还需要保证数据的一致性和可靠性，并支持高可用性和扩展性。

结合RabbitMQ、Kafka、RocketMQ的特征及优势，这个案例可以考虑RocketMQ和Kafka的组合方案，原因如下：

通过技术的发展和迭代，RabbitMQ、Kafka、RocketMQ在可用性和可靠性上都有一定的保障，不过相对Kafka和RocketMQ，RabbitMQ可能会存在单节点瓶颈问题，所以对可用性和稳定性要求较高的系统，RabbitMQ可以先被pass。
对于订单处理这类需要强一致性和可靠性的场景，使用RocketMQ作为主要的消息中间件，保证订单数据的实时性和一致性。
对于日志收集和实时数据分析这类大规模数据处理场景， Kafka的高吞吐量和流处理能力绝对是首选。

当面试官问"消息中间件如何选型"这个问题时，本质上是考察你对消息中间件的掌握程度以及你在团队中处于什么角色。所以，选型的前提是你要对需求和选型的竞品有足够的了解。