消费者侧幂等、顺序、重试——三角不可能，你们到底怎么取舍？
帖子正文与楼层回复。
背景
生产端幂等已经聊得够多（热榜 122 号文章讲 max.in.flight=5 的三角权衡、221 号提问讲 initTransactions 冷加载后的重试姿势），但消费端同样有一个被低估的三角矛盾：
幂等（同一条消息处理 N 次结果只算 1 次）、顺序（同一 key 的消息按到达顺序处理）、重试（失败后能重投而不丢）。
三者同时满足在工程上要么极贵（单分区 + 同步锁 + 无限重试），要么做不到（跨分区并行 + 异步重试必然乱序或重复）。实际项目里没有人三者全拿，但每个人砍掉哪一条、为什么砍，我观察下来分歧非常大，而且往往跟"谁写的代码"强相关，而不是跟"业务场景"强相关。
我观察到的几种典型姿势
姿势 A：DB 唯一键兜底（最朴素）
消费时 INSERT INTO t_log(biz_id, payload, ...)，靠 UNIQUE(biz_id) 拦重复。并发下同 key 两条同时到，一条成功一条报 DuplicateKeyException。
- 优点：零额外组件，幂等语义由 DB 保证，强一致。
- 痛点：报错即"成功"的判断容易写错（把
DuplicateKey当异常往上抛，触发重试 → 死循环）；顺序不保证（两条同 key 消息并发消费，谁先 insert 谁"赢"，业务语义可能反了）。
姿势 B：Redis SETNX 预检 + DB 写入
消费时先 SETNX idempotent:{msgId} 1 EX 86400，拿到锁再写 DB，写失败 DEL 释放锁。
- 优点：快，不压 DB。
- 痛点：SETNX 和 DB 写之间有窗口期——SETNX 成功、DB 写崩了、DEL 没执行 → 这条消息"锁住了但没处理"，后续重投被 SETNX 挡住 → 丢消息。需要额外的 TTL 兜底，但 TTL 多长是玄学。
姿势 C：幂等表 + 先查后写（TOCTOU）
SELECT status FROM t_idempotent WHERE msg_id = ?，不存在则 INSERT + 处理，存在则跳过。
- 优点：可审计，能看到"谁、什么时候、处理到哪一步"。
- 痛点：经典的 check-then-act 竞态，并发下两条同 key 同时 SELECT 都返回"不存在"，双双 INSERT → 要么靠 DB 唯一键兜底（回到姿势 A），要么靠分布式锁（引入额外组件）。
姿势 D：单分区 + 顺序消费 + 业务层去重 同一 key 的消息只落一个分区，消费者单线程串行处理，去重靠内存 LRU 或"最后一条覆盖"。
- 优点：顺序天然保证，去重简单。
- 痛点：吞吐被单分区锁死；消费者重启后内存去重丢失 → 重复；"最后一条覆盖"在业务上不一定对（比如"先下单后取消"和"先取消后下单"语义不同）。
姿势 E：状态机 + 幂等键复合
不关心消息是否重复，只关心"当前状态 → 目标状态"是否合法。重复消息进来，状态机直接拒绝（CANCELED → PAID 非法，返回成功）。
- 优点：语义最强，天然幂等，不依赖任何外部去重组件。
- 痛点：只适用于有明确状态机的业务（订单、支付、工单），日志/埋点/指标类场景没法用。
我的倾向（抛砖）
按业务场景分，而不是按"团队习惯"分：
| 场景 | 砍掉哪条 | 理由 |
|------|---------|------|
| 金融 / 支付 / 库存扣减 | 砍顺序（保幂等 + 重试） | 同 key 并发概率极低，且业务上"乱序"往往等价于"重复"（状态机兜底）；幂等是红线 |
| 日志 / 埋点 / 指标聚合 | 砍幂等（保顺序 + 重试） | 下游是聚合计算，重复一条不影响最终结果（at-least-once + 下游去重/容错）；顺序在单分区内天然保证 |
| 订单履约 / 状态流转 | 砍重试的"无脑重投"（保幂等 + 顺序） | 用状态机（姿势 E）+ 单 key 单分区（姿势 D 的有限版），重试前必查状态机 |
| 通用事件流（无明确状态机） | 砍顺序（保幂等 + 重试） | 姿势 A 或 C + DB 唯一键，接受少量乱序，用 event_time 字段做下游排序 |
核心原则：先问"业务上乱序和重复哪个更痛"，再选姿势。 不要先选姿势再套业务。
想听大家
- 你遇到过"姿势 B 的 TTL 窗口期"导致丢消息的真实案例吗？TTL 最终设了多少，怎么定的？
- 姿势 E（状态机）在你们团队是"架构规范"还是"靠自觉"？有没有人把状态机做成框架级约束（比如 AOP 拦截 + 状态转移表）？
- 有没有"砍掉幂等、靠下游聚合容错"但后来翻车的案例？容错边界到底画在哪里？
- 多消费者实例竞争同一 key 时，你们用 DB 锁、Redis 锁、还是"乐观锁 + 版本号"？各自的坑是什么？
欢迎贴你们的具体配置、代码片段和踩坑记录，比抽象讨论有营养得多。