3、消息队列基础：消息队列的核心概念、主流消息队列对比（Kafka/RocketMQ/RabbitMQ），消息队列在分布式事务中的角色
好，咱们进入第三章。这一章我打算聊聊消息队列的基础。你可能会问，分布式事务跟消息队列有什么关系？关系大了去了。说白了，消息队列是实现最终一致性的核心武器之一。我做了这么多年分布式系统，几乎每个涉及跨服务数据同步的场景，最后都绕不开消息队列。
3.1 消息队列的核心概念
先来捋一捋消息队列里那些绕不开的概念。嗯，这些概念你如果搞不清楚，后面写代码肯定会踩坑。
3.1.1 生产者与消费者
生产者（Producer）就是发消息的一方，消费者（Consumer）就是收消息并处理的一方。中间通过队列（Queue）或主题（Topic）来解耦。我在项目中遇到过一种情况：生产者疯狂发消息，消费者处理不过来，结果内存爆了。后来加了限流和背压机制才解决。
3.1.2 主题与分区
主题（Topic）是消息的逻辑分类。比如订单主题、支付主题。分区（Partition）则是物理上的拆分。为什么要分区？为了并行。你想想看，一个主题只有一个分区，那消费者只能串行处理，性能上不去。分区多了，多个消费者可以同时消费不同分区，吞吐量就上来了。
核心要点：分区数量决定了消费者的并行度。但分区也不是越多越好，太多分区会导致元数据管理开销变大，我建议根据实际流量来估算，一般每个分区每秒处理几百到几千条消息是比较合理的。
3.1.3 偏移量与消费位置
偏移量（Offset）是消息在分区内的唯一编号。消费者消费完一条消息后，会提交偏移量，表示「这条我处理完了」。如果消费者挂了重启，就从上次提交的偏移量继续消费。我曾经遇到过消费者处理完消息但没来得及提交偏移量就挂了，重启后重复消费了同一批消息。嗯，这里要注意：业务逻辑必须支持幂等性。
3.1.4 消息持久化
消息队列通常会把消息写到磁盘上，而不是只存在内存里。这样即使机器重启，消息也不会丢。Kafka 在这方面做得特别极致，它利用顺序写磁盘的特性，性能甚至比随机写内存还快。我刚开始接触时也觉得不可思议，后来自己压测了一轮，确实如此。
3.2 主流消息队列对比
市面上消息队列不少，但真正在生产环境大规模用的，也就那么几个。我挑三个最主流的：Kafka、RocketMQ、RabbitMQ。咱们从几个关键维度对比一下。
| 维度 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 开发语言 | Scala/Java | Java | Erlang |
| 吞吐量 | 极高（百万级/秒） | 高（十万级/秒） | 中等（万级/秒） |
| 消息可靠性 | 高（通过副本机制） | 高（同步刷盘+副本） | 高（确认机制） |
| 事务支持 | 有限（事务性生产者） | 强（完整分布式事务） | 弱（需插件扩展） |
| 延迟 | 毫秒级 | 毫秒级 | 微秒级 |
| 路由灵活性 | 低（基于Topic） | 中（支持Tag过滤） | 高（多种交换机类型） |
| 运维复杂度 | 中 | 中 | 低 |
3.2.1 Kafka：高吞吐的日志之王
Kafka 最初是为处理日志而生的。它的设计哲学就是「快」。顺序写磁盘、零拷贝、批量压缩，这些技术让它的吞吐量一骑绝尘。我个人习惯用 Kafka 做数据管道和流处理，比如把订单数据实时同步到数仓。但 Kafka 的事务支持比较弱，虽然 0.11 版本后引入了事务性生产者，但用起来限制不少。如果你要做分布式事务，Kafka 不是首选。
3.2.2 RocketMQ：阿里系的事务利器
RocketMQ 是阿里巴巴开源的，天生就为电商场景设计。它的分布式事务消息做得非常成熟——半消息机制、事务回查，这些功能在业界是独一份。我在做支付系统的最终一致性方案时，用的就是 RocketMQ。它的事务消息能保证「本地事务和消息发送」要么都成功，要么都失败。这一点在分布式事务里太关键了。
个人建议：如果你的业务对事务一致性要求高，比如金融、支付、订单场景，优先考虑 RocketMQ。它的事务消息虽然配置稍复杂，但用好了非常稳。
3.2.3 RabbitMQ：灵活的路由大师
RabbitMQ 基于 Erlang 开发，延迟极低，路由非常灵活。它有多种交换机类型：Direct、Topic、Fanout、Headers，可以满足各种复杂的路由需求。但它的吞吐量相对较低，而且原生不支持分布式事务。我一般用它来做内部服务之间的异步通知，比如用户注册成功后发邮件、发短信这种场景。如果硬要用 RabbitMQ 做分布式事务，需要自己实现一套补偿机制，比较麻烦。
3.3 消息队列在分布式事务中的角色
好，终于到重点了。消息队列在分布式事务里到底扮演什么角色？我总结了三层作用。
3.3.1 异步解耦
分布式事务最怕什么？怕同步调用。A 服务调用 B 服务，B 再调用 C 服务，任何一个环节出问题，整个链路都得回滚。引入消息队列后，A 服务只需要把消息发到队列里，然后告诉调用方「我处理完了」。B 和 C 自己去队列里拿消息处理。这样就把同步调用变成了异步通知，系统的可用性大幅提升。
3.3.2 最终一致性的保障
分布式事务不可能做到强一致，只能追求最终一致。消息队列就是实现最终一致性的核心载体。具体怎么做？我举个例子：订单服务创建订单后，发一条「订单已创建」的消息到队列。库存服务消费这条消息，扣减库存。如果库存扣减失败，消息会重试。重试多次还失败，就进入死信队列，人工介入处理。整个过程虽然有一段时间不一致，但最终会达成一致。
避坑指南：我曾经遇到过一个案例，消息重试次数设置得太少，导致大量消息进入死信队列，业务方投诉说订单扣了钱但库存没扣。后来我把重试次数从3次改成了15次，每次间隔指数递增，问题就解决了。重试策略一定要根据业务容忍度来设计。
3.3.3 事务消息与本地事务的绑定
这是消息队列在分布式事务中最核心的能力。以 RocketMQ 为例，它的流程是这样的：
- 生产者先发送一条「半消息」到 Broker，此时消息对消费者不可见。
- 生产者执行本地事务（比如插入订单数据到数据库）。
- 如果本地事务成功，生产者提交消息，Broker 让消息对消费者可见。
- 如果本地事务失败，生产者回滚消息，Broker 删除这条消息。
- 如果生产者挂了，Broker 会主动回查生产者的本地事务状态，决定是提交还是回滚。
你看，通过这种机制，本地事务和消息发送就绑定在一起了。要么都成功，要么都失败。这就是最终一致性的基石。
// RocketMQ 事务消息示例（伪代码）
TransactionMQProducer producer = new TransactionMQProducer("order_group");
producer.setTransactionListener(new TransactionListener() {
@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
// 执行本地事务，比如插入订单
boolean success = orderService.createOrder(arg);
return success ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE;
}
@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
// 回查本地事务状态
return orderService.checkOrderStatus(msg.getKeys()) ?
LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE;
}
});
producer.start();
// 发送半消息
SendResult result = producer.sendMessageInTransaction(message, orderData);
这段代码看着简单，但实际用起来坑不少。比如回查接口必须幂等，因为 Broker 可能会多次回查。还有，本地事务和消息发送的超时时间要协调好，不然容易出现「事务提交了但消息没发出去」的情况。
3.4 小结
这一章我们聊了消息队列的核心概念，对比了 Kafka、RocketMQ、RabbitMQ 三者的优劣，也讲清楚了消息队列在分布式事务中的角色。说白了，消息队列就是分布式系统的「缓冲带」和「粘合剂」。没有它，服务之间就是硬耦合，一荣俱荣一损俱损。有了它，大家各司其职，出了问题也能慢慢修复。
下一章我会深入讲 RocketMQ 的事务消息实现细节，包括半消息机制、事务回查的源码分析。到时候咱们再细聊。