2. 消息队列基础：主流MQ选型对比与核心概念
聊到消息队列，很多新手第一反应就是「选哪个好？」。我个人的习惯是，先别急着选，把几个核心概念吃透了，选型自然水到渠成。今天咱们就掰开揉碎了聊聊Kafka、RocketMQ、RabbitMQ这三兄弟，以及它们背后的Topic、Partition、Consumer Group这些绕不开的概念。
2.1 核心概念：Topic、Partition、Consumer Group
先说说Topic。你可以把它理解成一个「消息的分类标签」。比如订单系统发一个「订单创建」的消息，库存系统发一个「库存扣减」的消息，它们各自属于不同的Topic。说白了，Topic就是消息的逻辑通道。
那Partition呢？它是Topic的物理分片。我刚开始接触Kafka时，总觉得Partition是个玄学概念。后来在项目中遇到一个场景：单Topic的消费速度上不去，消息堆积严重。一查才发现，Partition数量太少，并发度不够。嗯，这里要注意：Partition的数量决定了消息的并行处理能力。每个Partition内部是有序的，但Partition之间不保证顺序。
核心关系：
- 一个Topic可以有多个Partition
- 每个Partition是一个有序的、不可变的消息序列
- 消息被追加到Partition的尾部，每个消息都有一个唯一的偏移量（Offset）
Consumer Group就更有意思了。它是一组消费者的集合，共同消费一个Topic的消息。我遇到过不少同学问：「同一个Consumer Group里的消费者，会不会重复消费？」答案是：不会。同一个Group内的消费者，每个Partition只会被一个消费者消费。这就是「点对点」模式。但如果多个Group订阅同一个Topic，那就是「发布-订阅」模式了——每个Group都会收到全量消息。
避坑指南：我曾经在一个项目中，把Consumer Group的消费者数量设得比Partition还多。结果发现多出来的消费者一直空闲，白白浪费资源。记住：消费者数量不要超过Partition数，否则多出来的消费者只能干瞪眼。
2.2 主流MQ选型对比
选型这事儿，说白了就是看场景。我这些年用过Kafka、RocketMQ、RabbitMQ，各有各的脾气。下面这张表是我个人的经验总结：
| 特性 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 定位 | 分布式流处理平台 | 低延迟、高可靠的分布式消息中间件 | 轻量级、易用的消息代理 |
| 吞吐量 | 极高（百万级/秒） | 高（十万级/秒） | 中等（万级/秒） |
| 延迟 | 毫秒级（批量处理） | 微秒级 | 微秒级 |
| 消息可靠性 | 高（通过副本机制） | 极高（支持同步刷盘） | 高（支持持久化） |
| 顺序消息 | Partition内有序 | 支持全局/分区顺序 | 需额外配置 |
| 事务消息 | 有限支持 | 原生支持 | 需插件 |
| 运维复杂度 | 高（依赖ZooKeeper） | 中 | 低 |
| 适用场景 | 日志收集、大数据管道、流处理 | 金融交易、订单系统、电商 | 微服务、任务队列、简单消息 |
你想想看，为什么Kafka的吞吐量能到百万级？因为它把消息批量写入磁盘，顺序I/O效率极高。但代价就是延迟稍高，不适合对实时性要求变态的场景。RocketMQ则是在延迟和吞吐之间找到了平衡，我做过一个金融项目，要求消息延迟不超过5毫秒，RocketMQ稳稳扛住了。
RabbitMQ呢？它是最容易上手的。我记得刚入行时，第一个接触的消息队列就是RabbitMQ。它的路由机制非常灵活，适合做任务分发。但如果你要处理海量数据，它可能就有点吃力了。
注意：选型不是选最好的，而是选最合适的。我曾经见过一个团队用Kafka做简单的任务队列，结果运维成本比业务代码还高。杀鸡焉用牛刀，对吧？
2.3 知识体系结构图
下面这张图，是我梳理的消息队列核心知识体系。你可以把它当作一张「地图」，后续学习时随时回来对照。
2.4 选型实战建议
说了这么多，到底怎么选？我给出三个典型场景，你对照着看：
- 场景一：日志收集与大数据分析 → 选Kafka。吞吐量是王道，顺序读写、批量处理，天生适合海量数据。
- 场景二：金融交易、订单系统 → 选RocketMQ。事务消息、低延迟、高可靠，这些是金融场景的命根子。
- 场景三：微服务异步解耦、任务队列 → 选RabbitMQ。上手快、路由灵活、运维简单，中小团队首选。
个人经验：如果你还在犹豫，我建议从RocketMQ入手。它功能全面，社区活跃，踩坑的代价也相对较小。我带的几个团队，现在基本都用RocketMQ作为主力MQ。
好了，这一章的核心内容就这些。记住：概念是骨架，选型是血肉。把Topic、Partition、Consumer Group的关系理清楚，后面的优化方案才能落地。