常用的主流消息中间件介绍与性能对比

　　消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削峰等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。
　　消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，作为提升应用性能的重要手段，分布式消息队列技术在互联网领域得到了越来越广泛的关注 。我们常用的分布式消息队列开源软件有：Kafka、ActiveMQ、RabbitMQ 及 RocketMQ。
　　消息队列是一种 ＂先进先出＂ 的数据结构；其中常运用的数据结构为链表（一般采用双向列表），其主要应用场景主要为3各方面：应用解耦、流量削锋、数据分发。
　　应用解耦：系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
　　消息中间件应用解耦示意图
　　流量削锋：应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。
　　消息中间件流量削锋示意图
　　数据分发：通过消息队列可以让数据在多个系统之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可。
　　消息中间件数据分发示意图ActiveMQ的优缺点
　　ActiveMQ:是 Apache 出品，最流行的，能力强劲的开源消息总线，并且它一个完全支持 JMS 规范的消息中间件。
　　优点：
　　1. 基于 JAVA，跨平台运行
　　2. 可以用 JDBC 连接多种数据库
　　3. 有完善的界面、监控、安全机制
　　4. 自动重连和错误重试
　　缺点：
　　1. 社区活跃度不及 RabbitMQ
　　2. 目前重心放到 6.0 产品 Apollo，对 5 的 Bug 维护较少
　　3. 不适合用于上千个队列的应用场景 RibbitMQ的优缺点
　　RibbitMQ:是使用 Erlang 语言开发的开源消息队列系统，基于 AMQP 协议来实现。
　　优点：
　　1. 基于 Erlang，支持高并发
　　2. 支持多种平台，多种客户端，文档齐全
　　3. 可靠性高
　　4. 在互联网公司有较大规模的应用，社区活跃度高
　　缺点：
　　1. Erlang语音较为小众，不利于二次开发
　　2. 代理架构下，中央节点增加了延迟，影响性能
　　3. 使用 AMQP 协议，使用起来有学习成本 RocketMQ的优缺点
　　RocketMQ:是阿里开源的消息中间件，目前也已经孵化为 Apache 顶级项目，它是纯 Java 开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。
　　优点：
　　1. 基于 Java，方便二次开发
　　2. 单机支持 1 万以上持久化队列
　　3. 内存与磁盘都有一份数据，保证性能+高可用
　　4. 开发度较活跃，版本更新很快
　　缺点：
　　1. 客户端种类不多，较成熟的是 Java、C++、GO等
　　2. RocketMQ 的官方文档相对简单一些
　　3. 社区关注度及成熟度不如 RabbitMQ Kafka的优缺点
　　Kafka:是 LinkedIn 开源的分布式发布-订阅消息系统，目前归属于 Apache 顶级项目。Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。
　　优点：
　　1. 原生的分布式系统
　　2. 零拷贝技术，减少IO操作步骤，提高系统吞吐量
　　3. 快速持久化：可以在O(1)的系统开销下进行消息持久化
　　4. 支持数据批量发送和拉取
　　缺点：
　　1. 单机超过64个队列/分区时，性能明显劣化
　　2. 使用短轮询方式，实时性取决于轮询间隔时间
　　3. 消费失败不支持重试
　　4. 可靠性比较差
　　消息中间件性能对比图
　　对比
　　ActiveMQ 最＂老＂，老牌，但维护较慢；
　　RabbitMQ 最＂火＂，各种场景通杀；
　　RocketMQ 最＂猛＂，功能强，但考验公司运维能力；
　　Kafka 最＂强＂，支持超大量数据，但消息可靠性弱。
　　结论：
　　中小型软件公司，建议选 RabbitMQ。一方面，erlang 语言天生具备高并发的特性，而且他的管理界面用起来十分方便。虽然RabbitMQ是开源的，但是国内能定制化开发erlang的程序员较少。所幸，RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑 rocketmq 和 kafka 的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以 kafka 排除。但是 rocketmq 已经交 apache管理，所以rocketmq 的未来发展趋势看好。
　　大型软件公司，根据具体使用在 rocketMq 和 kafka 之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ，大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改 JAVA 源码的人，还是相当多的。至于 kafka，根据业务场景选择，如果有日志采集功能，肯定是首选 kafka 了。具体该选哪个，看使用场景。