1. 消息队列基础：为什么交易系统需要消息队列？
做交易系统这些年，我见过太多系统因为耦合太紧而崩溃的例子。说白了，消息队列就是给系统装了个「缓冲带」。你想想看，交易系统每秒要处理成千上万笔订单，如果每个模块都直接调用，一个模块挂了，整个链条就断了。
我个人习惯把消息队列比作「邮局」。生产者是寄信人，消费者是收信人，消息就是信件。邮局不会因为收信人不在就拒收，它会暂存信件，等人来取。这就是解耦。
1.1 交易系统的三大痛点
我在项目中遇到过几次典型的「血案」：
- 耦合太紧：订单模块直接调用风控模块，风控一慢，订单就堵死
- 流量突刺：秒杀场景下，瞬间流量能把数据库打挂
- 数据丢失：系统重启后，未处理完的订单直接丢了
消息队列恰好能解决这三个问题。解耦、削峰、持久化，这是它最核心的价值。
核心价值总结：消息队列让交易系统从「紧耦合的同步调用」变成「松耦合的异步通信」。系统可用性从 99% 提升到 99.99%，靠的就是这个。
1.2 核心概念：生产者、消费者、主题、分区
这些概念其实不复杂。我换个说法你就懂了：
- 生产者（Producer）：发消息的一方。比如订单系统创建订单后，把订单消息发出去
- 消费者（Consumer）：收消息的一方。比如风控系统订阅订单消息，收到后做校验
- 主题（Topic）：消息的分类。就像快递上的「电子产品」「生鲜食品」标签
- 分区（Partition）：主题的物理分片。一个主题可以拆成多个分区，并行处理
嗯，这里要注意：分区是实现高吞吐的关键。我见过不少新手把消息全塞到一个分区里，结果性能还不如单机。分区数一般建议设置为消费者数量的整数倍。
避坑指南：我曾经在一个项目中，把分区数设得比消费者数还少。结果消费者空闲，消息却堆积在分区里。后来改成「分区数 = 消费者数 × 2」，吞吐量直接翻倍。
1.3 选型对比：Kafka vs RocketMQ vs RabbitMQ
选消息队列，说白了就是选「场景」。我整理了一张对比表，你一看就明白：
| 特性 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 吞吐量 | 百万级/秒 | 十万级/秒 | 万级/秒 |
| 延迟 | 毫秒级 | 毫秒级 | 微秒级 |
| 消息可靠性 | 高（副本机制） | 极高（同步刷盘） | 中（内存为主） |
| 事务支持 | 弱 | 强 | 弱 |
| 适用场景 | 日志、大数据、流处理 | 交易、订单、金融 | 轻量级、低延迟 |
我个人习惯这样选：
- 交易核心链路：用 RocketMQ。它的事务消息和顺序消息做得最好，金融场景首选
- 日志和监控：用 Kafka。吞吐量碾压其他，适合海量数据
- 内部通知、轻量任务：用 RabbitMQ。部署简单，延迟最低
注意：别盲目追求高吞吐。我见过有人用 Kafka 做订单系统，结果消息顺序乱了，对账对了一周。交易系统对顺序和事务的要求，比吞吐量更重要。
1.4 交易系统的消息队列架构图
下面这张图，是我画的一个典型交易系统消息队列架构。你一看就明白消息队列在中间扮演什么角色：
这张图里，订单、风控、支付系统作为生产者，把消息发到不同的 Topic。清算、通知、数据仓库作为消费者，按需订阅。消息队列在中间做缓冲，谁也不会拖累谁。
1.5 总结
消息队列不是银弹，但交易系统没有它，就像汽车没有减震。选型时记住三点：
- 交易核心用 RocketMQ，保顺序、保事务
- 日志监控用 Kafka，要吞吐、要速度
- 轻量任务用 RabbitMQ，要简单、要低延迟
嗯，这一章就到这里。下一章我们聊聊消息队列的「可靠性」——怎么保证消息不丢、不重、不乱序。这是交易系统的命根子。