MQ 系列的第二篇，主要介绍消息队列如何进行选型。

MQ2封面.png

1. 为什么要问技术选型

曾经有个面试官问了我这样一个问题：我看你简历上写用到了 Aivator 规则引擎，现在市面上有很多种规则引擎，你为什么要用这个，你是怎么做技术选型的？

当时我心里就一阵无力，还能怎么选型的？我一个刚毕业的你问我这？

当然是先网上搜一把大家都用什么规则引擎，结果一般是 drools 居多，其他还有 easy-rules、Aviator、QlExpress 等等，然后从中选择一个比较容易上手的，能完全满足业务需求的、性能又不差的，也能极快落地的就可以了，最终我选择的是 Aviator。

当然这个答案对于面试官来说是不太满意的，现在我也明白了这个问题的意义——面试官希望从你选型的思路中看到你的思考，不光是如何使用该框架实现业务，更多的其实是从框架性能、学习成本、业务贴合度、维护成本、拓展性以及异常排查等各个方面综合考虑，从而选择最合适，请注意是最合适而不一定是最好的技术框架。

说回到消息队列也是一样，都知道消息队列非常常用，并且大部分公司还是使用 RocketMQ 居多，那么为什么大家都这么选呢？如果你能在面试过程中有理有据的分析这个问题，讲得头头是道，那么对于面试官来说，你在日后进行其他技术、业务调研的时候可能也能从多方面综合考虑，选择一个对于项目最合适的方案进行实施，从而增大了你获得 Offer 的几率。

2. MQ 产品对比

市面上比较常见的消息队列产品有 ActiveMQ、RabbitMQ、RocketMQ、Kafka、Pulsar 等，下面是对这几个常用消息队列的对比。

ActiveMQ RabbitMQ RocketMQ Kafka Pulsar
诞生时间 2003 2007 2012 2012 2016
开发语言 Java Erlang Java Java & Scale Java
是否开源 是 是 是 是 是
社区活跃度 中 中 中 高 高
Star/Issue 2k/0.4k 9.5k/0.2k 17.2k/0.4k 22k/1k 10.8k/1.7k
单机吞吐量 万级 万级 10万+ 20万+ 100万+
产品成熟度 高 高 高 高 中
消息时效性 毫秒级 微秒级 毫秒级 毫秒级 毫秒级
消息可靠性 一般，有较低概率丢失 较好，基本不丢 很高，经参数配置可以做到0丢失 很高，经参数配置可以做到0丢失 很高
可用性 高（主从） 高（主从） 很高（分布式） 很高（分布式） 很高（分布式）
持久化 内存、文件 磁盘 磁盘 磁盘 磁盘
事务 支持 支持 支持 支持 支持
集群 支持 支持 支持 支持 支持
总结 MQ领域的老大哥，性能吞吐量较低，社区也不活跃 Erlang 语言开发导致有定制化开发成本较高，但支持较稳定 经历过大吞吐量验证，目前较为常用的产品 支持简单的 MQ场景，主要用于实时计算、日志采集等大数据场景 性能好，但产品成熟度相对较低

建议大家可以从性能（吞吐量、消息延时）、消息可靠性、产品可用性、社区活跃度、开发维护学习成本、

是否支持事务集群特性等方面来回答面试官的问题，结合自己实际项目上的需求来选择最合适项目的消息队列产品。

3. 参考

最后，本文收录于个人语雀知识库: 我所理解的后端技术，欢迎来访。