2. 消息队列选型与对比：RabbitMQ、Kafka、Redis Streams、NATS 的对比与选型策略
做量化交易系统，消息队列是绕不开的坎儿。
我见过不少团队，一开始随便选个 MQ，结果行情一上来，系统直接崩了。说白了，选错消息队列，就像给跑车装了个拖拉机的发动机——跑不起来。
今天咱们就聊聊市面上最主流的四个选手：RabbitMQ、Kafka、Redis Streams、NATS。我会结合我自己的踩坑经验，帮你理清楚到底该怎么选。
2.1 为什么量化交易系统需要消息队列？
先问个问题：你的交易系统里，行情数据、订单状态、风控信号，这些数据是怎么流转的？
很多人习惯用 HTTP 接口轮询，或者直接写数据库共享。嗯，小规模玩玩还行，一旦上了实盘，你就知道有多痛苦了。
- 解耦：行情模块只管推送，策略模块只管消费，谁也不依赖谁。
- 削峰填谷：行情爆发时，消息队列能帮你缓冲，不至于把下游打爆。
- 可靠传递：万一系统重启了，消息还在队列里，不会丢单。
我个人习惯，在实盘系统里至少用两层消息队列：一层给行情，一层给订单。各司其职，互不干扰。
2.2 四大消息队列的核心对比
咱们直接上干货。我把四个产品的核心特性整理成了表格，方便你一眼看明白。
| 特性 | RabbitMQ | Kafka | Redis Streams | NATS |
|---|---|---|---|---|
| 消息模型 | 队列/交换器 | 分区日志 | 流式结构 | 发布/订阅 |
| 吞吐量 | 万级/秒 | 百万级/秒 | 十万级/秒 | 十万级/秒 |
| 消息持久化 | 支持（磁盘） | 支持（磁盘） | 支持（RDB/AOF） | 支持（JetStream） |
| 延迟 | 微秒级 | 毫秒级 | 微秒级 | 微秒级 |
| 消息顺序 | 单队列有序 | 分区内有序 | 单流有序 | 单主题有序 |
| 运维复杂度 | 中等 | 高 | 低 | 低 |
| 典型场景 | 订单路由、任务分发 | 行情日志、海量事件 | 轻量级缓存+队列 | 微服务通信、低延迟 |
核心结论：没有银弹。每个产品都有自己的脾气，选型的关键是搞清楚你的场景到底要什么。
2.3 逐个拆解：我的实战经验
2.3.1 RabbitMQ —— 老牌稳重型选手
RabbitMQ 是我最早接触的消息队列。它的设计哲学很清晰：路由灵活，消息可靠。
我记得有一次做交易所的订单路由系统，需要把不同币种的订单分发到不同的处理节点。RabbitMQ 的 Topic 交换器简直就是为这个场景量身定做的。
- 优点：功能丰富，社区成熟，文档齐全。
- 缺点：吞吐量有上限，集群扩展不如 Kafka 方便。
适合场景：订单状态流转、任务分发、需要复杂路由逻辑的地方。
我的小技巧：RabbitMQ 的确认机制一定要用。我曾经因为没开 publisher confirm，丢了几笔订单，排查了一整天才发现是消息没发出去。
2.3.2 Kafka —— 海量数据的王者
Kafka 的定位很明确：高吞吐、持久化、流处理。说白了，它就是为大数据场景生的。
我在做行情数据采集时，每秒要处理几十万笔 tick 数据。用 Kafka 做缓冲层，下游的存储和计算模块完全扛得住。
- 优点：吞吐量天花板极高，数据持久化可靠，支持回溯消费。
- 缺点：运维成本高，延迟比 RabbitMQ 高一点，不适合低频小消息。
适合场景：行情日志、历史数据回放、事件溯源。
避坑指南：我曾经把 Kafka 用在订单系统里，结果发现延迟不稳定。后来才明白，Kafka 的设计目标是吞吐量优先，不是低延迟优先。订单系统还是用 RabbitMQ 更合适。
2.3.3 Redis Streams —— 轻量级多面手
Redis Streams 是 Redis 5.0 引入的功能。如果你已经在用 Redis，那它就是个「零成本」的消息队列。
我习惯用它来做实时风控信号的传递。因为风控逻辑本身就在 Redis 里做计算，直接用 Streams 推给下游，延迟极低。
- 优点：部署简单，延迟低，支持消费者组。
- 缺点：数据量大了之后内存压力大，持久化不如 Kafka 可靠。
适合场景：轻量级消息、实时计算、缓存+队列二合一。
我的建议：Redis Streams 适合做「临时队列」。比如盘中计算出的信号，推出去之后消费完就可以删掉。别用它存历史数据，那是 Kafka 的活。
2.3.4 NATS —— 极简低延迟之选
NATS 是个很有意思的产品。它的设计目标就是「简单、快速、可靠」。没有复杂的路由，没有持久化（原生版本），就是纯粹的发布/订阅。
我在做微服务之间的心跳检测和状态同步时，用过 NATS。它的延迟可以做到微秒级，比 RabbitMQ 还快。
- 优点：极低延迟，部署极其简单，资源占用少。
- 缺点：功能少，原生不支持持久化（需要 JetStream）。
适合场景：微服务通信、实时通知、对延迟极度敏感的场景。
注意：NATS 的 JetStream 扩展提供了持久化能力，但复杂度也上来了。如果你只需要简单的发布/订阅，原生 NATS 就够了。
2.4 选型策略：一张图看懂
说了这么多，到底怎么选？我画了一张流程图，帮你快速决策。
这张图的核心逻辑很简单：
- 吞吐量是硬指标，超过 10 万/秒，直接上 Kafka。
- 延迟敏感且不需要持久化，NATS 原生是首选。
- 需要持久化又想要低延迟，NATS JetStream 可以试试。
- 延迟不敏感但需要复杂路由，RabbitMQ 最稳。
- 如果只是轻量级场景，Redis Streams 够用。
2.5 我的最终建议
说了这么多，其实选型没有标准答案。我个人的经验是：
- 行情数据：用 Kafka。吞吐量大，能回溯，方便做历史回测。
- 订单状态：用 RabbitMQ。路由灵活，消息可靠，丢单是大忌。
- 风控信号：用 Redis Streams。延迟低，和 Redis 生态无缝集成。
- 微服务通信：用 NATS。简单、快、省资源。
最后提醒一句：别为了追求「技术新」而选一个不适合的中间件。我见过有人用 Kafka 做订单系统，结果运维成本翻了三倍，延迟还不稳定。选型之前，先想清楚你的核心诉求是什么。