消息队列与数据管道选型：Kafka vs Pulsar vs RabbitMQ
做市业务里，消息队列就是整个系统的「血管」。数据流不通，监控就是瞎子。我见过不少团队，一开始随便选个MQ，结果到后面数据回溯、扩容时痛不欲生。今天咱们就聊聊这三个主流选手——Kafka、Pulsar、RabbitMQ，到底该怎么选。
一、三大消息队列的核心差异
先给个直观对比，后面再细说。
| 特性 | Kafka | Pulsar | RabbitMQ |
|---|---|---|---|
| 设计定位 | 分布式流处理平台 | 云原生消息流平台 | 传统消息代理 |
| 存储模型 | 分区日志（磁盘） | 分层存储（BookKeeper） | 内存/队列（可选持久化） |
| 消息保留 | 基于时间/大小 | 可无限回溯 | 消费即删除（默认） |
| 吞吐量 | 百万级/秒 | 百万级/秒 | 万级/秒 |
| 运维复杂度 | 中等 | 较高 | 低 |
二、Kafka：做市监控的「老大哥」
我个人习惯把Kafka当作监控数据的默认选项。为什么？因为它天生就是为「海量数据、顺序读写」设计的。
做市业务里，行情数据、订单流水、成交记录，这些都是高吞吐、低延迟敏感的数据流。Kafka的分区机制正好匹配——每个分区内部保证顺序，不同分区可以并行消费。
核心优势：数据持久化能力强。默认保留7天数据，你可以配置到30天甚至更久。这意味着什么？出问题时，你可以回溯到任意时间点重新消费。
我在项目中遇到过一件事：某次做市策略出了bug，导致凌晨3点到5点的订单数据异常。幸好Kafka保留了48小时的数据，我们直接重置消费者偏移量，重新跑了一遍历史数据，问题定位只花了20分钟。要是用RabbitMQ，数据早就被消费删掉了。
分区策略怎么定？
嗯，这里要注意。分区数不是越多越好。我见过有人给一个topic设了100个分区，结果消费者组重平衡时花了5分钟，期间数据全部积压。
我的经验是：
- 按业务维度分区：比如按交易对、按策略ID。这样同一个交易对的数据始终在一个分区，顺序性有保障。
- 分区数 = 消费者线程数 × 2~3：留点余量，方便扩容。
- 避免热点分区：如果某个交易对数据量特别大，单独给它一个分区，别跟其他小交易对混在一起。
// 生产者分区策略示例
// 按交易对哈希取模，保证同一交易对进入同一分区
public class TradingPairPartitioner implements Partitioner {
@Override
public int partition(String topic, Object key, byte[] keyBytes,
Object value, byte[] valueBytes, Cluster cluster) {
String tradingPair = (String) key;
int numPartitions = cluster.partitionCountForTopic(topic);
return Math.abs(tradingPair.hashCode()) % numPartitions;
}
}三、Pulsar：云原生时代的「新贵」
Pulsar我接触得晚一些，但用下来确实有惊喜。它最大的特点是「存储与计算分离」。
说白了，Kafka的存储和计算是绑在一起的——每个broker既要存数据，又要处理请求。扩容时得搬数据，很麻烦。Pulsar不一样，数据存在BookKeeper里，broker只管计算。扩容时加broker就行，数据自动均衡。
适用场景：如果你的做市系统部署在Kubernetes上，Pulsar是更好的选择。它原生支持容器化，扩缩容非常灵活。
Pulsar还有一个杀手锏——无限数据回溯。Kafka的数据保留受磁盘限制，Pulsar可以配置分层存储，冷数据自动迁移到S3或HDFS。理论上你可以回溯到任意历史时间点。
我曾经帮一个客户做监控系统升级，他们需要保留3个月的行情数据用于回测分析。用Kafka的话，磁盘成本太高。换成Pulsar后，热数据在SSD上保留7天，冷数据自动转到对象存储，成本降了60%。
消费者模型对比
Kafka和Pulsar的消费者模型有本质区别：
- Kafka：一个分区只能被同一个消费者组内的一个消费者消费。想提高并行度？加分区。
- Pulsar：支持「共享订阅」模式。一个分区可以被多个消费者同时消费，消息自动负载均衡。
这个差异在做市监控里很重要。比如你有一个「订单延迟监控」的topic，数据量不大但需要多个消费者做不同维度的分析。用Kafka的话，你得建多个topic或者手动分配分区。Pulsar直接共享订阅就行，省事很多。
四、RabbitMQ：轻量级场景的「老黄牛」
RabbitMQ不是不能用，只是场景要选对。它擅长的是「低延迟、高可靠、复杂路由」的场景。
做市系统里，哪些场景适合RabbitMQ？
- 告警通知：告警消息量不大，但要求实时送达，而且需要灵活的路由规则（比如按告警级别、按负责人）。
- 操作指令：比如手动调整参数、暂停策略。这些消息必须可靠送达，不能丢。
- 内部RPC调用：RabbitMQ的RPC模式很成熟，适合做服务间同步调用。
避坑指南：我曾经见过有人用RabbitMQ处理行情数据，结果每秒10万条消息就把队列压垮了。RabbitMQ的吞吐瓶颈在万级/秒，千万别拿它当Kafka用。
五、数据持久化与回溯能力
做市监控最怕什么？数据丢了查不到原因。所以持久化和回溯能力是选型的核心考量。
我画了一张图，帮你理清思路：
六、我的选型建议
说了这么多，到底怎么选？我总结一下：
- 主力监控数据管道：选Kafka。生态成熟、社区活跃、踩坑经验多。做市业务90%的场景都能覆盖。
- 需要长期回溯：选Pulsar。特别是你有回测分析、合规审计需求时，Pulsar的分层存储是杀手锏。
- 轻量级辅助管道：选RabbitMQ。告警、指令、RPC这些场景，RabbitMQ更轻便、更灵活。
- 混合架构：我现在的做法是Kafka + RabbitMQ混用。Kafka扛主数据流，RabbitMQ处理管理消息。各取所长。
最后说一句：选型没有银弹。别盲目追求「最新最热」，适合你业务场景的才是最好的。我见过用Kafka做告警通知的，也见过用RabbitMQ扛行情数据的，结果都不太理想。想清楚你的核心需求——吞吐量、持久化、回溯能力、运维成本，排个优先级，答案自然就有了。
公众号:蓝海资料掘金营，微信deep3321