第二大脑

主题

2026-08-24
639
2.2m

概念卡片：消息队列对比（RabbitMQ / Kafka / RocketMQ） ​

一句话机制：三大消息队列各有定位——RabbitMQ 功能均衡、协议标准（AMQP）、延迟低，适合业务解耦；Kafka 高吞吐、持久化、分区有序，适合日志/大数据流；RocketMQ 阿里出品、事务消息强、可抗双十一级流量，适合电商金融。

三大 MQ 对比 ​

维度RabbitMQKafkaRocketMQ
协议AMQP自定义（基于 TCP）自定义（类 Kafka 架构）
吞吐量万级百万级（顺序写 + 零拷贝）十万级
延迟微秒~毫秒级毫秒级毫秒级
有序性单队列有序分区内有序队列有序（支持顺序消息）
事务消息弱弱强（半消息 + 回查）
定位业务解耦（通用）日志/大数据流/流处理电商/金融（阿里系）

Kafka 为何快（四要点） ​

  • 顺序读写：追加写日志，避免随机磁盘寻址
  • 零拷贝：数据不经用户态拷贝，直接内核传输
  • 消息压缩：Producer 压缩（gzip/snappy/lz4）
  • 分批发送：消息攒批次批量写入

Kafka 核心术语 ​

术语说明
Topic消息分类（类比数据库表）
Partition主题分区，分布在不同 broker，分区内有序
Consumer Group消费者组，组内共享分区（一个分区只被组内一个消费者消费）
Offset消费偏移量，记录消费位置，重平衡后恢复
Rebalance消费者组内实例增减/宕机时重新分配分区的过程

不变量（必须成立的约束） ​

  • Kafka 是分区内有序，不是全局有序；要全局有序需单分区。
  • 消费者的数量不应超过分区数，多出来的消费者会闲置。
  • RabbitMQ 是推消息（push），Kafka 是拉消息（pull）——消费者主动 poll 拉取。
  • 选型：业务解耦/低延迟 → RabbitMQ；日志/大数据流/高吞吐 → Kafka；电商/金融/事务消息 → RocketMQ。

踩坑案例 ​

  • 现象：Kafka 消费者数量加多了，吞吐却没提升。 原因：消费者数超过分区数，多余的消费者闲置。解决：消费者数 ≤ 分区数，或增加分区。

常见误解 ​

  • 以为「消息队列都差不多」→ 吞吐量、有序性、事务消息能力差异巨大，选错代价高。
  • 以为 Kafka 能全局有序 → 只有分区内有序。

关联 ​

最近更新