中间件RabbitMQ-常见消息队列中间件选型

一、什么是消息队列中间件

消息队列中间件是分布式系统中一个非常重要的组件，主要解决应用程序的解耦、异步消息、缓冲、流量削峰等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统和高并发、大数据流量场景必不可少的中间件，同时也是支撑高可用的常用手段之一。

二、消息队列的应用场景

• 高并发场景下起到消息缓存作用，当某个或者某段时间内有大量用户访问我们的系统或者有大量的请求需要去处理，这时候使用消息队列异步去处理可以非常高效的解决同一时刻并发流量的问题。

• 有与第三方系统产生数据交互时、在交互的数据量大、交互工作量重时，可不选择通过接口交互，Producer可以直接将消费者Consumer需要的消息丢到队列中，广播出去。

• 在使用Go、Java、Python等不同语言中，可以屏蔽操作系统底层复杂的通讯细节，使用MQ中间件进行通讯，连接各个语言端，解决跨平台作用。

三、主流的消息中间件对比

在日常的开发过程中，使用较多的消息队列中间件有ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ、MetaMQ，其中前4者使用居多，通常在ActiveMQ、RabbitMQ、RocketMQ、KafKa这4者中进行选型，选出一种适合于我们当前业务的消息队列中间件。

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
开发语音	java	erlang	java	scala
单机吞吐量	万级	万级	10万级	10万级
时效性	ms级	us级	ms级	ms级以内
可用性	高（主从架构）	高（主从架构）	非常高（分布式架构）	非常高（分布式架构）
功能特性	成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好	基于erlang开发，所以并发能力很强，性能极其好，延时很低管理界面较丰富	MQ功能顺序消息、事务消息等功能完善比较完备，扩展性佳	只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广
应用	适合中小企业，不适合上千个队列的应用	适合对稳定性要求高的企业级应用	阿里系下开源的一款分布式的消息中间件，多用于订单交易系统	应用在大数据日志处理 或对实时性、可靠性(少量数据丢失)要求较低的场景

1. ActiveMQ(文档虽然很完善，但是比较老，吞吐量不及其他组件，现在很少用)

• 单机吞吐量：万级

• topic数量都吞吐量的影响：

  时效性：ms级

  可用性：高，基于主从架构实现高可用性

  消息可靠性：有较低的概率丢失数据

  功能支持：MQ领域的功能极其完备

• 总结：
  非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息，现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本，主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用

2. RabbitMQ(延迟极其低、MQ功能完善，界面友好，但是使用erlang语言编写，难维护)

• 单机吞吐量：万级

• topic数量都吞吐量的影响：

  时效性：微秒级，延时低是一大特点。

  可用性：高，基于主从架构实现高可用性

  消息可靠性：

  功能支持：基于erlang开发，所以并发能力很强，性能极其好，延时很低

• 总结：　　
  erlang语言开发，性能极其好，延时很低；
  吞吐量到万级，MQ功能比较完备 ，开源提供的管理界面非常棒，用起来很好用 ，社区相对比较活跃，几乎每个月都发布几个版本分 ，在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。

  erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。

  rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。

3. RocketMQ(国内组织阿里巴巴开源，功能最完善，吞吐量高，性能仅次于kafka，架构借鉴于kafka，推荐使用)

• 单机吞吐量：十万级

• topic数量都吞吐量的影响：topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。可支持大量topic是一大优势。

  时效性：ms级

  可用性：非常高，分布式架构

  消息可靠性：经过参数优化配置，消息可以做到0丢失

  功能支持：MQ功能较为完善，还是分布式的，扩展性好

• 总结：
  接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景

  而且一个很大的优势在于，源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控

  社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码

阿里巴巴：

https://help.aliyun.com/document_detail/29532.html?spm=a2c4g.11186623.6.542.c87170fb58btRJ

消息队列 RocketMQ 是阿里巴巴集团基于高可用分布式集群技术，自主研发的云正式商用的专业消息中间件，既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性，是阿里巴巴双 11 使用的核心产品。

4. Kafka(底层采用TCP协议通讯、零拷贝机制，性能极其高，适用于日志收集等大数据统计领域)

• 单机吞吐量：十万级，最大的优点，就是吞吐量高。

• topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源

  时效性：ms级

  可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用

  消息可靠性：经过参数优化配置，消息可以做到0丢失

  功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

• 总结：
  kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展 ，同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量

  kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略