无声如风做游戏饰品交易这行，最怕的不是流量小，而是流量突然爆发时消息中间件先倒。我们平台“悠悠有品”从日活几千到高峰期每秒上万笔请求，中间件的选型和演进踩了不少坑。最终定下来的方案很清晰：核心交易链路用 RocketMQ 稳扛，海量行为数据和日志管道交给 Kafka 驱动。这篇文章把整套技术选型逻辑、落地细节和排查过程完整写出来，希望能给正在做高并发交易平台的朋友一些参考。
先说结论：RocketMQ 和 Kafka 不是二选一的关系，而是各管一段。RocketMQ 负责订单、支付、发货这类强一致性和事务性要求极高的核心交易链路，Kafka 负责埋点、日志、行为数据这种海量写入和吞吐优先的数据管道。两者配合下来，系统扛住了多次大促和热门饰品首发活动的流量高峰。
1. 业务画像与消息选型逻辑
1.1 游戏饰品交易平台的三个典型特征
悠悠有品做的是游戏饰品交易，比如 CS2 的皮肤、DOTA2 的饰品、各类游戏的装备和道具。这类平台和传统电商最大的区别在于商品是虚拟资产，单价高、流动性强、用户价格敏感度高，几个特征直接决定了技术架构的走向。
第一个特征是请求量脉冲式暴涨。热门饰品上新、比赛结束后的价格波动、大主播带货，都会在几分钟内把流量拉高几十倍。平时每秒一千笔请求的系统，瞬间可能要扛住每秒上万笔。这种场景下，消息中间件如果撑不住，订单就直接丢失，用户资金和饰品都会出问题。
第二个特征是业务链路长且状态多。一笔交易从用户下单、卖家确认、饰品暂扣、买家付款、平台担保、饰品发放到最终确认收货，中间涉及十几个状态变更。任何一个环节的消息丢失或乱序，都会造成资损级别的故障。
第三个特征是海量行为数据需要留存分析。用户浏览了哪些饰品、搜索了什么关键词、点击了哪个商品详情页、 在哪个页面停留了多久，这些数据每天产生几十亿条，必须全部收集起来用于推荐、风控和运营分析，任何一条都不能丢，但延迟几百毫秒完全可以接受。
这三个特征叠加在一起，单一消息中间件很难同时满足。强一致、强事务、状态机复杂的交易链路要的是“稳”，海量写入、高吞吐、允许适度延迟的数据管道要的是“快”。RocketMQ 和 Kafka 的组合，本质上是为这两个截然不同的需求分别选择最合适的工具。
1.2 为什么交易链路选 RocketMQ 而不是 Kafka
早期团队也有人提过用 Kafka 一把梭，毕竟 Kafka 吞吐高、生态好、社区活跃。但真正把交易场景的需求列出来后，RocketMQ 的优势就非常明显了。
事务消息是第一个决定性因素。交易系统里有一个非常经典的问题：本地数据库事务和消息发送如何保证原子性。比如用户下单时，需要同时写入订单表、扣减卖家库存、冻结买家资金，还要发送一条消息通知后续系统。如果先写库再发消息，消息发送失败就要回滚数据库；如果先发消息再写库，下游系统可能拿到消息时订单还不存在。RocketMQ 的事务消息机制解决了这个问题，通过 half 消息加本地事务状态回查，保证了消息和数据库操作的最终一致性。Kafka 原生没有事务消息，虽然可以通过回调接口模拟，但实现复杂度和可靠性都差很多。
顺序消息是第二个关键点。饰品交易中同一笔订单的消息必须严格有序，比如“已支付”消息不能比“已下单”消息先到，“已发货”消息不能比“已支付”先到。RocketMQ 支持队列级别的顺序消息，把同一业务 ID 的消息路由到同一个队列，消费者按顺序拉取。Kafka 虽然也能通过分区实现局部有序，但分区数量和消费者并发度的关系很微妙，一旦消费者数量超过分区数，顺序就会被打破。
延迟消息是第三个加分项。交易平台有大量超时场景：用户下单后 30 分钟未支付自动取消，卖家发货后 48 小时未确认自动完成。RocketMQ 内置 18 个延迟级别，直接设置即可使用。Kafka 本身不支持延迟消息，需要自己实现时间轮或者用 Redis 延迟队列做兜底。在已经足够复杂的交易系统里，少一个自研组件就少一份维护成本。
还有一个非常现实的考量：RocketMQ 是 Java 写的，我们团队后端主力是 Java 技术栈，遇到底层问题可以直接看源码修复，出现问题也能通过社区快速联系到核心维护者。Kafka 是 Scala 写的，虽然问题不多，但真到了需要改源码的程度，团队投入成本就高了。
1.3 数据链路为什么离不开 Kafka
交易链路选完 RocketMQ 后，数据管道这边几乎没有任何争议地选了 Kafka。原因很直接：吞吐量差距明显，生态配套成熟。
游戏饰品平台的用户行为数据量极其庞大。用户每打开一次 App，首页曝光、列表滑动、详情点击、价格曲线查看、卖家主页访问等至少产生十条以上的埋点数据。按 100 万日活、人均 200 条埋点计算，一天就是 2 亿条数据，高峰期每秒产生几万甚至十几万条写入。RocketMQ 并不是不能扛这个量级，但在同样资源消耗下，Kafka 的吞吐明显更高。Kafka 采用顺序写磁盘和零拷贝技术，单分区顺序写性能可以跑到每秒百万条级别，这是日志型数据管道的天然优势。
Kafka 的生态也是重要因素。我们的大数据链路是 Flink 做实时计算、Elasticsearch 做搜索和推荐、ClickHouse 做 OLAP 分析、HDFS 做离线数仓，这些组件基本都有成熟的 Kafka Connector 和官方集成方案。Flink 消费 Kafka 写入 Elasticsearch 是标准得不能再标准的链路，配置一下就能用。RocketMQ 虽然也有这些生态，但成熟度和坑的数量还是比 Kafka 多一些。
此外，Kafka 的消息堆积能力极强。数据管道经常出现下游短暂故障的场景，比如 Elasticsearch 集群重启、Flink 任务发布新版本，消息在 Kafka 里堆积几亿条完全没问题，恢复后继续消费即可。Kafka 的数据保留策略也灵活，可以按时间和大小双重控制，消息过期自动清理，不需要人工干预。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心交易链路：RocketMQ 的稳字诀
2.1 订单主流程的消息模型设计
先画一下订单主流程的简化模型，大家感受下消息在交易链路中是怎么流动的。用户下单时，订单服务在本地数据库写入订单记录，同时发送一条“下单成功”的 RocketMQ 消息。库存服务消费这条消息，预扣饰品库存，然后发送“库存锁定成功”消息。支付服务消费消息后，向用户发起支付请求。用户支付成功后，支付回调服务发送“支付成功”消息，订单服务消费后更新订单状态，同时发送“待发货”消息触发卖家发货流程。卖家发货后，仓库服务发送“已发货”消息，买家确认收货后，订单服务发送“已完成”消息，整个交易闭环结束。
这个模型里，每条消息都对应一个明确的状态变更事件，消费者收到消息后只做