消息队列MQ选型 - Kafka、RabbitMQ对比

适应场景

异步处理，应用解耦，流量削锋和消息通讯

RabbitMQ：使用erlang开发的开源消息队列，通过erlang的actor模型实现了数据的稳定可靠传输，支持AMQP、XMQP、SMTP等多种协议，因此也比较重量级。由于采用broker代理架构，发送给客户端时，先在阻塞队列进行排队，rabbitMQ的单机吞吐量在万级。

kafka：由scala开发的高性能、跨语言、分布式消息队列，单机吞吐量可以达到10w级，消息延迟在毫秒级，kafka是完全分布式系统，broke、consume、produser都是原生自动支持分布式，依赖于zoopkeer做分布式协调，kafka支持一写多读，消息可以被多个服务端消费，消息有可能会重复，但是不会丢失。

对比

feature	scenario	Kafka	RabbitMQ	备注
PUB-SUB 发布订阅模型		√	√
推拉消费	Consumer消费消息的动作方式。	pull	push/pull	push更关注实时性。pull更关注消费者消费能力。
延迟消费	Producer产生一条消息后，并不希望立刻被消费掉。	X	√	高阶需求。
consumer group	同一条Message能同时被多个消费组消费，但同一group中，一条Message只会被一个consumer消费	√	√	KAFKA: 不需要在管理平台配置。 RabbitMQ：增加需要配置，涉及到内部数据冗余。
消息tag(filter)	以过滤出tag为keyword的message	X	X
消息回溯	从历史中的某个位置重新拉取消息	X	X	只对拉模式，推模式不考虑回溯，支持时间维度offset
事务性	mq内部逻辑，消息状态是否一致	X	√	和消息中间件内部实现相关。
优先级	消息优先级，consumer优先消费高优先级消息。	X	√
染色	追踪消息在mq中的具体耗时	X	X
本地读优化	Producer\Consumer 不在同一机房。MQ搭建在P端，C端会存在跨机房访问的问题。	X	X	使用数据同步工具，将P所在机房数据同步到C所在机房的集群。
doubt message(消息追踪)	跨公司，异构系统间，消息状态追踪。	X	X
消息积压	没有被消费的消息在MQ中堆积	√	√	支持程度的区别，不同mq会存在不同。
负载均衡	1：防止单点 2：C端压力LB在MQ各节点上。	√	√	RMQ：多集群做负载
支持的消息大小	每条消息的大小	无限制	无限制	需要对消息大小做限制，降低系统不确定性。
定期回收消息	mq中的消息一旦被消费后，可以被删除，空间回收。	√	√
消费语义	方式分别为：1、最多消费一次 2、最少消费一次3、仅消费一次	2	2	业务方消费端做幂等
对全局序支持	消息在全局保持时序一致	X	X	设计复杂度原因，不考虑支持

备注：
“√” 表示目前系统已主持
“X” 表示系统不考虑支持该特性

链接：https://www.jianshu.com/p/20f9be3c45d3