适应场景
异步处理,应用解耦,流量削锋和消息通讯
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” 表示系统不考虑支持该特性