事件顺序的边界应该如何定义？
简化版
消息顺序通常只应保证到业务实体或聚合根，例如同一订单按序，而不是追求全局顺序。选定 orderId 等稳定 key 路由到同一分区，并由单个消费执行流处理；跨实体关系用版本、状态机或因果依赖解决。
详细版
先写出哪些事件交换顺序会破坏不变量，再把它们归入同一 ordering key。Broker 只保证分区日志顺序，生产重试、多个 producer、并行消费和死信绕过都可能破坏业务观察顺序，因此消息携带 entityVersion/sequence，消费者只接受合法迁移。
全局单分区虽有总序，却牺牲吞吐和可用性，通常没有业务价值。热点 key 可按子资源拆分，前提是不变量也能拆；扩分区和更换哈希算法要处理同一 key 在迁移窗口落到不同分区的问题。
完整版教学
一、先定义“谁和谁”要有序
订单 Created 必须先于 Paid，但订单 A 与订单 B 通常无需比较。库存与订单若属于不同服务，也很难靠一条全局队列获得端到端事务顺序。顺序边界应来自业务不变量，而非技术上的“全部排好”。
记忆钩子：顺序不是 Topic 属性，而是某个业务 key 上的约束。
二、分区如何提供局部顺序
相同 key 经稳定分区器进入同一 partition，日志按 offset 排列；消费组让该分区同一时刻由一个成员持有。若应用把分区消息丢进无序线程池，Broker 顺序仍会在业务层被打乱。
partition = hash(orderId) % N
order-7: Created(v1) -> Paid(v2) -> Shipped(v3)三、生产端也会制造乱序
两个 producer 同时更新同一订单，网络重试可能让后发请求先到。幂等 producer 可减少同一会话重试乱序，但不能替代业务单写者或版本。事件应携带聚合版本，并由权威写入事务分配。
聚合版本不能由各 producer 读取当前值后自行加一，否则并发读取会生成相同版本；应由权威存储通过事务、CAS 或日志位置分配。
| 风险 | 技术顺序 | 业务防线 |
|---|---|---|
| 同 producer 重试 | 可能支持 | producer sequence |
| 多 producer | 无统一顺序 | 聚合版本/CAS |
| 并行消费 | 完成乱序 | key 串行 |
| 跨分区 | 无顺序 | 状态机/因果依赖 |
四、消费者如何处理缺口
当前已处理 v5，收到 v4 应忽略或当重复；收到 v7 表示 v6 缺失，可短暂等待、查询权威快照或进入修复队列。不能简单按到达顺序覆盖状态。
等待必须有时限，例如 30 秒后仍无 v6 就查询源服务并告警，否则一个永久缺失事件会无限阻塞 key。
五、死信与重试的顺序代价
v2 失败后若直接处理 v3，状态可能非法；整个分区停住又会影响无关 key。可按 key 建阻塞/重试队列，让其他 key 继续，或把同 key 后续事件一起隔离。选择要明确吞吐与严格性的取舍。
重放时保持原 key 与版本，不能换随机 key 绕过原分区语义。
六、扩分区与热点治理
从 8 扩到 16 分区后 hash%N 会改变大量 key 路由，旧分区仍有未消费事件时，新旧会并行。可冻结生产并排空、使用稳定路由表/一致性哈希，或让消费者以 entityVersion 抵御迁移乱序。
单个超级热点订单无法靠增加分区并行，因为其不变量要求串行；应合并写、缩短处理或重新拆分业务实体。
拆分热点 key 前要证明跨子资源不再共享同一约束；若仍需全局余额或总量校验，拆分只会把串行点移动到下游。
七、常见误区与追问
- 误区：一个 Topic 天然全局有序。 多分区之间没有总顺序。
- 误区：同分区就一定业务顺序。 并行处理和多 producer 仍会打乱。
- 误区：单分区是最稳妥方案。 会形成吞吐和可用性瓶颈。
- 误区：扩分区不影响已有 key。 取模变化会改变路由。
- 追问：ordering key 怎么选？ 选共享同一不变量的聚合根 ID。
- 追问：版本跳跃怎么办？ 有界等待后查权威快照并告警。
- 追问：毒消息能否跳过？ 取决于同 key 后续事件是否依赖它，应隔离而非盲跳。
八、加强记忆
顺序设计按“业务不变量—ordering key—同分区—单 key 串行—版本校验”展开。只为真正相关的事件付出顺序成本；生产重试、并行消费、死信和扩分区都要重新检查边界。版本状态机是 Broker 顺序之外的最终防线。