Several MQ product descriptions: ZeroMQ : It has good scalability and flexible development. It is implemented in C language. In fact, it is just a repackage of a socket library. If we use it as a message queue, we need to develop a lot of code. RabbitMQ : Combined with erlang language It has its own concurrency advantages and good performance, but it is not conducive to secondary development and maintenance of ActiveMQ : an open source project with a long history, which has been applied in many products and implements the JMS1.1 specification, which can be easily integrated with spring-jms to achieve It supports a variety of protocols, which is not lightweight enough (more source code than RocketMQ). It supports persistence to the database, and does not support the situation with a large number of queues. However, we will not build many queues in our project. Redis is a The memory-based KV database provides message subscription services and can be used as MQ. Currently, there are few application cases, and it is inconvenient to expand RocketMQ : Alibaba's MQ middleware, used in multiple products, and can To support the large traffic of Double Eleven, he did not implement the JMS specification, and it is very simple to use. The deployment consists of a naming service (nameserver) and a broker (broker). Both the nameserver, broker and producer support clustering. The capacity of the queue is limited by the hard disk of the machine. After the queue is full, it can be persisted to the hard disk (or you can adapt the code yourself). , persist it to the NOSQL database), the throughput will be affected when the queue is full, the master and backup can be used to ensure stability, support retrospective consumption, and message filtering can be performed on the broker side. The selection of message middleware can be from the following aspects Consider: (mainly comparing ActiveMQ and RocketMQ)
Priority: This requirement is not particularly obvious in our project. RocketMQ needs to create a new special queue to receive high-priority queues. It is impossible to achieve fine-grained control from 0-65535. ActiveMQ can finely control
the order: our message bus The messages in should be stateless, so there are no strict requirements for the processing order of messages. If there are special requirements, it can be controlled at the business layer. ActiveMQ cannot guarantee strict order, and RocketMQ can guarantee strict consumption order
persistence: Both support
stability: RoketMQ may be more reliable in terms of stability, and supports a variety of cluster solutions. After all, it has already supported several double eleven
message filtering: ActiveMQ only supports judging whether it is the message it needs when it is consumed by the client , RocketMQ can filter on the broker side. For our message bus, it can save a lot of network transmission. Whether there will be repeated consumption caused by message retransmission: RocketMQ can guarantee, ActiveMQ can not guarantee
retrospective consumption: that is, retransmitting a certain time before We should have very little demand for this kind of message. RocketMQ supports it, but ActiveMQ does not support it (RocketMQ queues are persisted to the hard disk, and
transactions are cleared regularly: all support
timed consumption: RocketMQ supports
message accumulation: that is, when cache The solution after the message memory is full, one is the discard strategy, which will not affect the throughput, and the other is to persist the message to the disk, which will affect the throughput. In evaluating the degree of impact, RocketMQ's The performance is slightly better.
The client is not online: RocketMQ can continue to push unconsumed messages to the client after the client is online.
The comparison of several MQ middleware products that are currently active are as follows: (only open source projects are counted)
| ActiveMQ | RabbitMQ | RocketMq | ZeroMQ | |
| Attention | high | high | middle | middle |
| maturity | Mature | Mature | more mature | immature |
| Affiliated Community/Company | Apache | Mozilla Public License |
Alibaba | |
| 社区活跃度 | 高 | 高 | 中 | 低 |
| 文档 | 多 | 多 | 中 | 中 |
| 特点 | 功能齐全，被大量开源项目使用 | 由于Erlang 语言的并发能力，性能很好 | 各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好 | 低延时，高性能，最高 43万条消息每秒 |
| 授权方式 | 开源 | 开源 | 开源 | 开源 |
| 开发语言 | Java | Erlang | Java | C |
| 支持的协议 | OpenWire、 STOMP、 REST、XMPP、 AMQP |
AMQP | 自己定义的一 套(社区提供 JMS--不成熟) |
TCP、UDP |
| 客户端支持语言 | Java、C、 C++、 Python、 PHP、 Perl、.net 等 |
Java、C、 C++、 Python、 PHP、Perl 等 |
Java C++（不成熟） |
python、 java、 php、.net 等 |
| 持久化 | 内存、文件、数据库 | 内存、文件 | 磁盘文件 | 在消息发送端保存 |
| 事务 | 支持 | 不支持 | 支持 | 不支持 |
| 集群 | 支持 | 支持 | 支持 | 不支持 |
| 负载均衡 | 支持 | 支持 | 支持 | 不支持 |
| 管理界面 | 一般 | 好 | 无社区有 web console 实现 |
无 |
| 部署方式 | 独立、嵌入 | 独立 | 独立 | 独立 |
| 评价 | 优点： 成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端； 缺点： 根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了，目前社区不活跃，且对 5.x 维护较少； Activemq 不适合用于上千个队列的应用场景 |
优点： 由于erlang语言的特性，mq 性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客户端可用 缺点： erlang语言难度较 大。集群不支持动态扩展。 |
优点： 模型简单，接口易用（JMS 的接口很多场合并不太实用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产 品均使用rocketmq。集群规模大概在50 台左右，单日处理消息上百亿；性能非常好，可以大量堆 积消息在broker 中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本更新很快。 缺点： 没有在 mq 核心中去实现JMS 等接口， |