MQ称为Message Queue 解决项目之间的耦合问题 解决A和B项目之间的通信
主流MQ对比:Kafka、RocketMq、RabbitMq
Kafka:Apache下的子项目,使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统(用于日志领域)
- 快速持久化:通过磁盘顺序读写与零拷贝机制,可以在O(1)的系统开销下消息持久化
- 高吞吐:在一台普通服务器上既可以达到10w/s的吞吐速率
- 高堆积:支持topic下消费者较长时间离校,消息堆积量大
- 完全的分布式系统:Broker、Producer、Consumer都原生自动支持分布式,依赖zookeeper自动实现负载均衡
- 支持Hadoop数据并行加载:对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案
RocketMq:前身是Metaq,发布3.0时改名为RocketMq。RocketMq是一款分布式、队列模型的消息中间件(正常业务)
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 支持事物消息
- 亿级消息堆积能力比kafka低一点点
RabbitMq:使用Erlang编写的开源的消息队列,本身支持很多的协议:AMQP,XMPP,SMTP,STOMP,使它变的非常重量级,适合于企业级的开发
- 路由(Routing)
- 负载均衡(Load balance)
- 数据持久化
Kafka | RocketMq | RabbitMq | |
设计定位 | 系统间的数据流管道,实时数据处理 例如:常规的消息系统、网站活跃性跟踪、监控数据、日志收集
| 非日志的可靠消息传输 例如:订单,交易,充值,流计算,消息推送,binlog分发
| 可靠消息传输和RocketMq类似
|
所属社区 | Apache | Alibaba开发,假如Apache下 | Mozilla Public License |
开发语言 | Scala | Java | Erlang |
支出协议 | 一套自行设计的基于TCP的二进制协议 | 自定义的一套 | AMQP
|
客户端语言 | C/C++、Python、Go、Erlang、Ruby、Node.js、Java、PHP等 | Java | Java、C/C++、Python、PHP |
持久化方式 | 磁盘文件 | 磁盘文件 | 内存、文件 |
部署方式 | 单机/集群 | 单机/集群 | 单机/集群 |
集群管理 | zookeeper | name server | |
选主方式 | 从ISR中自动选举一个leader | 不支持自动选主。通过设定brokername、brokerid实现,brokername相同,brokerid=0时为master其他为slave | 最早入集群的broker |
可用性 | 非常高 分布式、主从 | 非常高 分布式、主从 | 高 主从,采用镜像模式实现,数据最大时可能产生性能瓶颈
|
主从切换 | 自动切换 N个副本,允许N-1个失效;master失效以后自动从ISR中选择一个主 | 不支持自动切换 master失效以后不能向master发送消息,consumer大概30s可以感知此事件,此后从slave消费;如果master无法恢复,异步复制此时可能出现部分信息丢失 | 自动切换 最早加入集群的slave会成为master;因为新加入的slave不会同步master之前的数据,所以可能回出现部分数据丢失 |
数据可靠性 | 很好 支持producer单条发送、异步刷盘、同步复制,但这种场景下性能明显下降 | 很好 producer单条发送,broker端支持同步刷盘,同步双写,异步复制 | 好 producer支持同步/异步ack,支持队列数据持久化,镜像模式中支持主从同步 |
消息写入性能 | 非常好 每条10个字节测试:百万条/s | 很好 每条10个字节测试:单机单broker越7w/s,单机3broker约12w/s | RAM约为RocketMq的1/2 Disk的性能为RAM性能的1/3 |
定时消息 | 开源版本仅支持定时Level | ||
事务消息 | 不支持 | 支持 | 不支持 |
消息查询 | 不支持 | 根据MessageId查询 | 不支持 |
优点 | 1、高吞吐、低延迟、高可用、集群热扩展、集群容错上变现非常好 2、producer端提供缓存、压缩功能,可节省性能,提高效率 3、提供顺序消费能力 4、提供多种客户端语言 5、生态完善,在大数据处理方面 有大量配套设施 | 1、高吞吐、低延迟、高可用、消息堆积、性能很好 2、api、系统设计更下适合在业务处理场景 3、支持多种消费方式 4、支持broker消息过滤 5.支持事物 6、提供消息顺序消费能力;consumer可以水平扩展,消费能力很强 7、集群规模在50台左右,单日处理消息上百亿;经历过大数据量的考验,比较稳定可靠 | 1、在高吞吐量、高可用上前两者都有所不如 2、支持多客户端语言;支持amqp协议 3、由于erlange语言特性,性能比较好,使用RAM模式时,性能很好 4、管理界面非常丰富 |
缺点 | 1、消费集群数目受到分区数目限制 2、单机topic多时,性能会明显降低 3、不支持事务 | 1、相比于kafka,消息推挤、吞吐率也有所哺乳 2、不支持主从自动切换,master失效后,消费者要一定的时间才能感知 3、客户端只支持java | 1、erlang语言难度较大,集群不支持动态扩展 2、不支持事务、消息吞吐能力有限 3、消息堆积时,性能会明显下降 |