image.png
适应场景
异步处理，应用解耦，流量削锋和消息通讯
对比
| 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” 表示系统不考虑支持该特性
个人介绍：
高广超 ：多年一线互联网研发与架构设计经验，擅长设计与落地高可用、高性能互联网架构。
