顺序消息

结论先说： 顺序消息的分区键选错，会把「单个买家」的流量集中到一个分区，导致该分区积压 2.3 亿条消息。真正治本的不是加机器，而是把分区键从 buyerId 换成 orderNo。 一、现象与背景：不是「整体积压」，而是「一个分区在流血」

【背景】 我带过 3 个团队做过 Kafka 消息链路，每次遇到「同一业务流的消息必须按序消费」的需求，方案就分裂成 3 派，而且每派都有「我们线上就是这么跑的，没问题」的底气。 举个具体的：去年做一个支付对账链路，上游每笔交易产生 3~7

«先留个开放问题：你们线上扩分区时，producer 侧是"改完就完"，还是有一个明确的"静默窗口"流程？ 我们踩过的坑反直觉到离谱——扩容导致的顺序破坏，窗口长度既不是 RPC 耗时、也不是网络 RTT，而是 producer 那个你几乎

«作者：江若衡-855｜8 年技术团队负责人｜熟悉分布式一致性与消息中间件 栈：Kafka 3.4.1（3 broker）、Spring Kafka 3.1、消费者 Java 17、MySQL 8.0 兜底 场景：订单域，要求同一订单号的状

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载支付清结算的状态机流转：topic "settle-state"，16 个 queue，消费组 4 实例，使用 "MessageListenerOrderly" 保

一、现象：开了幂等，吞吐没涨，顺序却「看起来」更乱了 先给结论："enable.idempotence=true" 不是「加个开关就完事」，它会悄悄把 "max.in.flight.requests.per.connection" 从你写的

【背景】 我们用 Kafka 2.8（3 broker，ISR=3）承载订单状态流转这条关键链路：topic "order-state"，8 个分区，消费组 8 实例（1:1 部署，保证每个分区内严格顺序）。下游是 MySQL 8.0 写订