消息队列ActiveMQ、RocketMQ、RabbitMQ和Kafka如何选择？
很多年前, 新浪微博的研发负责人TimYang老师在微博架构设计的演讲中，引用了一句话:
Databases are specializing – the “one size fits all” approach no longer applies -- MongoDB设计哲学
这种哲学同样可以适用于消息队列。
ActiveMQ和RabbitMQ算是老一辈的消息队列。在2012年左右还是广泛的在各个公司里使用。
但在高堆积和异构这两个场景表现不尽如人意。
▍ 高堆积场景
当时我还服务于一家互联网彩票公司 ，选用ActiveMQ。因为业务增长很快 ，每天的消息量从日均5万增长到日均100万。但我们越来越忧心，我们发现ActiveMQ在面对高堆积的场景下，显得越来越力不从心，消费者hang住的情况越来越常见。不得已，公司技术团队在设计消费者的时候，先从消息队列里取出消息，存在本地文件里，然后异步消费。这样消息堆积的几率下降很多。
去哪儿也很早大规模使用ActiveMQ , 但他们在使用过程中经常出现消息丢失或者整个进程hang住的情况 , 而RabbitMQ是erlang语言编写的，团队无法驾驭，只能另起炉灶 ，研发了QMQ。
京东最开始也是大规模使用ActiveMQ。我在读《京东消息中间件演进之路》这篇文章时候，作者提到:
- Broker较重，采用B-Tree索引，性能随消息积压量的上升急剧下降；
- Broker端采用的VirtualTopic模式针对一个Topic有多个订阅者的情况会对每个订阅者单独存储一份消息。而京东的生产环境中大部分都是采用VirtualTopic并且每个Topic订阅者都很多，举个例子，比如“订单管道”消息：它有将近100个订阅者，也就是同一个数据要写将近100份，不仅如此，这100份消息还要通过网络发送到Slave上，经过这些流程，写入TPS只能达到几百。
京东也是发现了ActiveMQ无法匹配他们的需求，慢慢发展出他们自己的JMQ。
▍ 异构场景
这两种消费场景ActiveMQ和RabbitMQ显得左支右绌，只能采取消息复制的偏门手段曲线救国。
- 集群消费 如下图 , 专车订单生成后，会发送一条消息到队列，需要通知派单系统，推送服务，BI系统。
- 广播消费
双十一大促时，各个分会场会有玲琅满目的商品，每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求，缓存服务器网卡满载。访问较多次商品价格查询影响会场页面的打开速度。
此时需要提供一种广播机制，一条消息本来只可以被集群的一台机器消费，如果使用消息队列广播消费模式，那么这条消息会被所有节点消费一次，相当于把价格信息同步到需要的每台机器上，取代缓存的作用。
2012年，Apache Kafka诞生了。这是一个全新设计的消息队列。它天然支持高堆积，异构场景。 同时它在日志同步领域大放异彩 ，甚至于某种程度上成为事实上的标准。
阿里最开始也使用Kafka，但因为Kafka是Scala开发的，他们对Scala不熟，另外阿里内部有些需求kafka没有实现，比如事务、多种offset存储等。所以阿里自己参考Kafka，研发出了MetaQ。后来，他们发现在多分区条件下，MetaQ有IO瓶颈等问题。 所以MetaQ的升级版RocketMQ诞生了。 2015年，RocketMQ捐献给了Apache，成为Apache顶级项目。
随着移动互联网和大数据爆发 ，Kafka/RocketMQ在各大公司越来越广泛的使用，围绕着他们也生态也越来越繁荣。而同时，ActiveMQ和RabbitMQ显得就落寞很多。
相信未来，技术的发展，场景的变化，理论的突破，也许新的消息队列也会出现，又或者新的模型代替了消息队列也未可知。这是客观的规律。