3、消息中间件选型与部署：Kafka vs RabbitMQ，主题与分区设计
做量化交易系统，消息中间件是绕不开的坎儿。我见过不少团队，一开始图省事直接用Redis做消息队列，结果行情一上来就崩。说白了，选对消息中间件，就是给系统上了一道保险。
今天咱们聊聊两个主流选择：Kafka和RabbitMQ。我会结合自己的实战经验，把它们的区别、适用场景，还有主题和分区的设计思路，一次性讲清楚。
3.1 Kafka vs RabbitMQ：核心差异
先问个问题：你的系统是更看重吞吐量，还是更看重消息的灵活路由？
我个人习惯这样区分：
- Kafka：天生为高吞吐、持久化、流式处理而生。适合做日志收集、行情分发、事件溯源。
- RabbitMQ：擅长复杂路由、消息确认、灵活的消息模式。适合做任务调度、命令分发、异步解耦。
我在项目中遇到过这样的情况：用RabbitMQ做行情分发，结果每秒几万笔的Tick数据直接把队列压垮了。后来换成Kafka，同样的硬件配置，吞吐量提升了10倍不止。
核心结论：
- 行情数据、订单流水、日志 → 选Kafka
- 交易指令、风控通知、任务调度 → 选RabbitMQ
3.2 主题与分区设计：Kafka的核心
Kafka里，主题（Topic）是逻辑上的消息分类，分区（Partition）是物理上的存储单元。嗯，这里要注意：分区数决定了你的并行处理能力。
我建议遵循以下原则：
- 分区数 = 消费者线程数：一个分区只能被一个消费者线程消费。分区数太少，消费者会闲置；太多，会增加管理开销。
- 按业务维度划分主题：比如行情数据，可以拆成
tick_data、order_book、trade_data三个主题。别把所有东西塞到一个主题里。 - 分区键设计：用交易品种作为分区键，保证同一个品种的数据顺序一致。
实战技巧：
我曾经把一个行情主题分了64个分区，结果发现大部分分区是空的。后来改成按品种哈希分区，每个品种一个分区，既保证了顺序，又充分利用了资源。
3.3 RabbitMQ的Exchange与Queue设计
RabbitMQ的核心是Exchange（交换机）和Queue（队列）。消息先到Exchange，再根据路由键分发到不同的Queue。
我常用的模式：
- Direct Exchange：精确匹配路由键。适合点对点通信，比如把订单指令发给指定的交易系统。
- Topic Exchange：通配符匹配路由键。适合按品种或策略分类，比如
order.btc.usdt匹配所有BTC订单。 - Fanout Exchange：广播给所有绑定的队列。适合全局通知，比如系统重启、风控触发。
避坑指南：
我曾经在RabbitMQ里用了太多临时队列，结果内存爆了。后来我强制规定：每个队列必须设置 max-length 和 message-ttl，防止消息堆积。
3.4 部署架构对比
| 维度 | Kafka | RabbitMQ |
|---|---|---|
| 集群模式 | 天然分布式，依赖ZooKeeper或KRaft | 镜像队列或Quorum队列 |
| 数据持久化 | 磁盘顺序写，性能极高 | 内存+磁盘，消息确认后删除 |
| 消息顺序 | 分区内严格有序 | 单队列内有序 |
| 运维复杂度 | 较高，需要调优参数 | 较低，管理界面友好 |
你想想看，如果你的系统需要处理百万级TPS的行情数据，Kafka几乎是唯一选择。但如果是几十个交易策略之间的指令交互，RabbitMQ更轻量、更灵活。
3.5 主题与分区设计实战
下面是我在一个实盘项目中用过的设计，你可以参考：
# Kafka主题设计
主题: market_data
分区: 按品种哈希 (btc, eth, sol...)
保留策略: 7天
压缩: 启用
主题: order_events
分区: 按订单ID哈希
保留策略: 3天
压缩: 禁用
# RabbitMQ队列设计
队列: order_executor
绑定: direct exchange
路由键: order.execute
死信队列: order_executor_dlq
队列: risk_check
绑定: topic exchange
路由键: risk.#
最大长度: 10000
关键点：
Kafka的分区数一旦设定，后期扩容很麻烦。我建议一开始就按未来2年的峰值预估。比如当前需要8个分区，直接设成16个，留有余量。
3.6 消息中间件选型决策树
为了让你更直观地理解，我画了一张流程图：
这张图的核心逻辑很简单：先看吞吐量需求，再看消息类型。别纠结，选对了中间件，后面的事就顺了。
3.7 总结与个人建议
说了这么多，其实就一句话：没有最好的中间件，只有最合适的。
我个人习惯这样搭配：
- 行情系统用Kafka，分区数按品种数×2来设
- 交易指令用RabbitMQ，每个策略一个队列，用Topic Exchange做路由
- 风控事件用RabbitMQ的Fanout Exchange，广播给所有订阅方
最后一个小建议：
不管选哪个，一定要做好监控。Kafka的消费者滞后、RabbitMQ的队列堆积，都是实盘中的隐形杀手。我曾经因为没监控到Kafka消费者挂了，导致行情数据丢了半小时，那教训太深刻了。
好了，消息中间件这块就聊到这儿。记住：选型是第一步，部署和调优才是持久战。