Event Sourcing 消费端崩溃重投时，幂等靠 sequence CAS 还是本地 event_log 表？

【背景】 我们在做一个交易流水的事件溯源系统：Kafka 3.5（3 broker）承载 tx-event topic（32 分区，per-transaction 顺序保证），消费者是 16 实例的 Java 服务。每个事件携带 tx_id + event_seq（业务递增序号），消费者将事件追加到本地 event_log 表（MySQL 8.0），再更新业务状态表 order_state。

【卡点】 核心问题：消费者在「处理完事件、更新本地状态」之后、提交 Kafka offset 之前崩溃。重启后 offset 回退，同一条事件被重新消费。此时幂等保证靠什么？我们内部两种方案在争：

方案 A（sequence CAS）：消费时 UPDATE order_state SET version=? WHERE order_no=? AND version < ?，靠业务版本号做乐观锁。问题：状态表只存「当前版本号」不存历史事件，重放 seq=6 时不知道 seq=5（部分退款）已执行过，业务语义丢失。

方案 B（本地 event_log 去重表）：消费前先 SELECT 1 FROM event_log WHERE tx_id=? AND event_seq=?，有记录就跳过。问题：日均 2000 万事件，event_log 表已 40 亿行，归档任务每周跑一次 P99 延迟 45 分钟；归档窗口内的重投如何处理？

【已尝试】

• 方案 A 压测通过，但业务方不接受「状态表不存历史事件」
• 方案 B 跑了 3 个月，大表问题越来越严重
• 考虑过 Redis 做去重（TTL=7 天），但运维担心 Redis 故障时去重丢失
• 也看过「Kafka offset 本身当版本指针」的思路，但 offset 是 consumer group 粒度的，多实例下不好用

【期望得到的答案形态】

1. 你们在 Event Sourcing / 事件溯源场景下，消费端崩溃重投的幂等方案具体是什么？（表结构 DDL、关键 SQL、TTL / 归档策略）
2. 如果 event_log 表已经很大，归档策略怎么设计？按时间还是按 seq 范围？归档后「归档窗口内的重投」怎么兜底？
3. 有没有人用过「Kafka offset 当版本指针 + 本地 event_log 做二次校验」的混合方案？实际效果如何，踩过什么坑？
4. 更开放地：如果让你重新设计，你会不会干脆放弃「消费端自己做幂等」，改用「Kafka 事务 + 本地事务」的 atomic commit 语义？性能预算够吗？