四种消息队列，如何选型？( 四 ) _消息队列

支持发布/订阅和点对点消息模型，支持拉、推两种消息模式；

提供 Docker 镜像用于隔离测试和云集群部署，提供配置、指标和监控等功能丰富的 Dashboard 。

缺点：

不支持消息路由，支持的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟；
部分支持消息有序：需要将同一类的消息 hash 到同一个队列 Queue 中，才能支持消息的顺序，如果同一类消息散落到不同的 Queue中，就不能支持消息的顺序。
社区活跃度一般。

3.3 RabbitMQ优点：

支持几乎所有最受欢迎的编程语言：Java，C ， C ++，C＃，Ruby，Perl，Python/ target=_blank class=infotextkey>Python，php等等；
支持消息路由：RabbitMQ 可以通过不同的交换器支持不同种类的消息路由；
消息时序：通过延时队列，可以指定消息的延时时间，过期时间TTL等；
支持容错处理：通过交付重试和死信交换器（DLX）来处理消息处理故障；
提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker；
社区活跃度高。

缺点：

Erlang 开发，很难去看懂源码，不利于做二次开发和维护，基本职能依赖于开源社区的快速维护和修复 bug；
RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重；
不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般。

04 消息队列选型Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 。
RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ 。
RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug 。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ 。
ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。

【四种消息队列，如何选型？】