主流消息队列比较 · 分布式系统开发

**1.ZeroMQ** 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失；**Twitter的Storm中使用ZeroMQ作为数据流的传输** **2.RabbitMQ** 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。性能较好，但是不利于做二次开发和维护 **3.ActiveMQ** 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好 **4.Kafka/Jafka** Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性： * 快速持久化，可以在O(1)的系统开销下进行消息持久化； * 高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡； * 支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。 Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统 ### 当前主流MQ比较 | | kafka | RocketMQ | RabbitMQ | | --- | --- | --- | --- | | 设计定位 |系统间的数据流管道，实时数据处理，例如常规的消息系统，监控数据日志的收集处理 | 非日志消息的可靠传输，例如订单、交易、充值、消息推送等 | 可靠消息传输，和RocketMQ类似 | | 成熟度 | 成熟 | 成熟 | 成熟 | | 社区/公司 |apache |alibaba/已捐献给apache | | | 社区活跃度 | 高 | 中 | 高 | | 文档 | 完备 | 完备 | 完备 | |开发语言 | scala | java | erlang | | 协议 |自定义基于TCP的二进制协议 |自定义 |AMQP | | 多语言支持 |c/c++/python/go/erlang/.net/Ruby/node/java/php | java |java/c/c++/python/php/perl | |持久化方式 |磁盘文件 |磁盘文件 |内存/文件 | |部署方式 |单机/集群 |单机/集群 | 单机/集群 | |集群管理 |zookeeper | name server | | |选主方式 |从ISR中自动选举一个Leader |不支持自动选主 |最早加入集群的Broker | |主从切换 |自动切换 |不支持自动切换 | 自动切换 | |数据可靠性 |支持producer单条发送/同步刷盘/同步复制 |单条发送/同步刷盘/异步刷盘/同步双写/异步复制 | | |堆积能力 | 非常好，消息存储在log，每个分区一个Log | 非常好，消息存储在同一个commitlog |一般 | |消息过滤 |不支持 | 支持 | 不支持 | | 消息重试 |不支持 | 支持 |支持 | | 消费方式 |consumer pull | consumer pull/ broker push | broker push | | 部署依赖 |zookeeper | name server | erlang环境 | | 管理后台 |官方不提供 | rocketmq-console |rabbitmqadmin | |优点 |1.高吞吐、低延迟、高可用、集群热扩展、集群容错； 2.支持多语言客户端； 3.生态完善，在大数据处理方面有大量配套设施 |1.高吞吐、低延迟、高可用，消息堆积时性能也很好； 2.系统设计更加适合业务处理场景； 3.支持多种消费方式； 4.支持broker消息过滤； 5.支持事务； 6.支持顺序消息； 7.集群规模50台左右，单日处理消息上百亿，经历过大数量验证，比较可靠稳定 | 1.高吞吐、高可用不如前两者； 2.支持多语言客户端；支持AMQP协议； 3.由于erlang语言的特性，性能较好；互联网公司有大规模应用 | |缺点 | 1.消费集群数目受到分区数目限制； 2.单机topic多时性能明显降低； 3.不支持事务 |1.相比于Kafka使用者较少，生态不够完善；消息堆积、吞吐率也有所不如； 2.不支持主从自动切换，master失效后，consumer需要一定时间才能感知(30s)； 3.客户端只支持JAVA |1.erlang语言难度较大，集群不支持动态扩展； 2.不支持事务、消息吞吐能力有限； 3.消息堆积时性能明显降低 |