消息中间件产品对比介绍
前言
消息队列中间件选择时要根据项目的实际需求，考虑系统的吞吐量、延迟、可靠性、可扩展性等因素。
消息中间件产品对比一
| 消息队列 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Kafka | 日志收集、大数据处理、实时流处理 | 高吞吐量、高扩展性 | 不支持复杂消息模型，有一定学习成本 |
| RabbitMQ | 企业消息传递、即时通讯、延时任务 | 灵活的路由、支持多协议 | 吞吐量较低，扩展性一般 |
| RocketMQ | 交易系统、订单系统、金融系统 | 高性能、支持分布式事务、顺序消息 | 社区支持一般，维护门槛高 |
| ActiveMQ | 小规模企业集成、跨平台消息传递 | 灵活、协议支持多 | 性能低，扩展性有限 |
消息中间件产品对比二
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比 RocketMQ 和 Kafka 要低了一个数量级 | 万级，吞吐量比 RocketMQ 和 Kafka 要低了一个数量级 | 10 万级，支持高吞吐 | 10 万级别，这是 Kafka 最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景。 |
| Topic 数量对吞吐量的影响 | Topic 可以达到几百、几千个的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 Topic | Topic 从几十个到几百个的时候，吞吐量会大幅度下降，所以在同等机器下，Kafka 尽量保证 Topic 数量不要过多。如果要支撑大规模 Topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级，这是 Rabbitmq 的一大特点，延迟是最低的 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用性 | 高，基于主从架构实现高可用性 | 非常高，分布式架构 | 非常高，Kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢失 | 经过参数优化配置，可以做到零丢失 | 经过参数优化配置，消息可以做到零丢失 |
| 功能支持 | MQ 领域的功能极其完备 | 基于 Erlang 开发，所以并发能力很强，性能极其好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
| 优缺点总结 | (1) 非常成熟，功能强大，在过去业内大量的公司以及项目中都有使用 (2) 偶尔会有较低概率丢失消息 (3) 目前社区以及国内使用的公司都越来越少了，官方社区现在对 ActiveMQ 5.x 维护越来越少，几个月才发布一个版本 (4) 确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 | (1) Erlang 语言开发，性能极其好，延时很低 (2) 吞吐量到万级，MQ 功能比较完备 (3) 开源提供的管理界面非常棒，用起来很好用 (4) 社区相对比较活跃，几乎每个月都发布几个版本 (5) 在国内一些互联网公司近几年用 Rabbitmq 也比较多一些 (6) 但是问题也是显而易见的，RabbitMQ 确实吞吐量会低一些，这是因为它的实现机制比较重 (7) 基于 Erlang 开发，但国内有几个公司有实力做 Erlang 源码级别的研究和定制呢？如果说没这个实力的话，确实偶尔会遇到一些问题，并且很难去看懂源码，一旦你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复 Bug (8) Rabbitmq 集群动态扩展会很麻烦，不过这个其实还好，其实最主要的还是 Erlang 语言本身带来的问题，很难读源码，很难定制和掌控 | (1) 接口简单易用，而且毕竟在阿里大规模应用过，有阿里品质保障 (2) 日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是 OK 的，还可以支撑大规模的 Topic 数量，支持复杂 MQ 业务场景 (3) 而且一个很大的优势在于，阿里出品都是 Java 系的，我们可以自己阅读源码，定制自己公司的 MQ，可以掌控 (4) 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的，有些系统要迁移需要修改大量代码 (5) 还有就是阿里开源的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力，我觉得用 RocketMQ 挺好的 | (1) Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展 (2) 同时建议 Kafka 最好是支撑较少的 Topic 数量，这样可以保证其超高吞吐量 (3) 而且 Kafka 唯一的一点劣势是有可能出现消息重复消费，对数据准确性会造成极其轻微的影响，在大数据领域以及日志采集中，这点轻微影响可以忽略不计 (4) 这个特性天然适合大数据实时计算以及日志收集 |
消息中间件产品对比总结
综上所述，各种消息中间件对比之后，可以得出以下结论（仅供参考）：
- (1) 很久以前，一般的业务系统要引入 MQ，大多数公司都会用 ActiveMQ，但是现在越来越少公司会使用它了，因为 ActiveMQ 没经过大规模吞吐量场景的验证，社区也不是很活跃，所以不推荐用 ActiveMQ。
- (2) 后来很多公司开始用 RabbitMQ，但是 Erlang 语言确实阻止了大量的 Java 工程师去深入研究和掌控它。对公司而言，RabbitMQ 几乎处于不可控的状态，但是 RabbitMQ 是开源的，有社区提供比较稳定的技术支持，活跃度也高。
- (3) 不过现在越来越多的公司会使用 RocketMQ，确实很不错，但是最好提醒一下自己想好社区万一突然黄掉的风险。如果对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ，毕竟 RabbitMQ 有活跃的开源社区，绝对不会黄掉。
- (4) 对于中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择。对于大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
- (5) 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题。Kafka 的社区活跃度很高，绝对不会黄掉，更何况 Kafka 几乎是全世界这个领域的事实性规范。