Kafka 单分区有序被业务耗时差异打破：幂等表挡不住乱序落库，怎么保单调性？

背景：订单服务用 Kafka，按 order_id 做 partition key 保证同单有序。消费者单线程顺序消费，处理逻辑是「解析 → 幂等表查重（dedup 表用 message_id 做唯一键，SELECT ... FOR UPDATE）→ 写业务库 → 提交 offset」。

现象：压测和线上都偶现「后到的状态覆盖先到的」。具体是：同一 order_id 的两条消息 M1（改地址，业务事务慢，~800ms）和 M2（改金额，快，~50ms）顺序进入消费者。因为 M1 业务事务慢，M2 先处理完并提交；M1 随后才提交。最终库里落的是 M1 的旧值——单分区的「顺序」在落库这一步被打破了。关键是幂等表对这种情况完全无效：M1、M2 的 message_id 不同，查重都通过，去重表挡不住「乱序」只能挡住「重复」。

已尝试：1）单线程消费保证不并行，无效，问题出在「耗时差异」不是并发；2）给 dedup 表加唯一键防重，对乱序无效；3）想过按 partition 起内存串行队列，但进程重启会丢队列状态，且引入新故障点。

想请大家给的具体答案形态：你们在生产里到底怎么保证「同一 key 的写操作按业务语义单调落地」？期望能对比 2~3 种可落地方案并说清取舍，比如：a) 每条消息带单调 version/seq，写库时 WHERE version > 当前值做乐观拒绝（乐观锁/水位线）；b) 把「消费」和「落库」解耦，用 per-key 内存串行 + 持久化水位；c) 干脆放弃消费端保序，改用幂等 + 最终一致 + 读时合并。请尽量给出真实的表结构/字段设计（version 列怎么存、怎么初始化、冲突时返回什么）和踩过的坑，别只给结论。