消息消费幂等与重放：把重复投递变成可判断的业务状态

同一订单消息可能收到多次，幂等要保证重复处理不会重复产生业务效果，而不是保证永远收不到重复。写成状态变化，就是 f(f(S,e),e)=f(S,e)，其中 e 必须始终表示同一次操作。余额加十本身不幂等；按版本设置目标状态较容易避免重复，但也要防旧版本盖过新版本。先说明怎样辨认同一次请求，别把两次合法但内容相同的操作误当重复。

发送超时后，发送方不一定知道对方是否已做完。数据库提交了但 ack 丢了，消息就可能再次投递；历史重放也会带回旧事件。eventId 应在事实首次产生时确定，重试继续用它；同一 ID 却带不同内容，应当报告冲突。业务事件、每次发送尝试和消费者收到的投递，需要分别记录，才能看清一件事被尝试了多少次。

去重前还要回答：这是哪个租户、哪种操作的哪一件事？例如积分发放和订单审计都收到 event-1，不应因为事件编号相同就互相挡住。可以把租户 tenant、处理操作 handler、事件编号 eventId 合起来作为唯一键。

再把请求内容按约定整理后计算摘要，与最终结果、处理版本一起保存，用来识别“编号相同但内容不同”。这些信息必须来自或经过可信业务上下文验证，不能让用户冒用别人的编号取走旧结果，或挡住别人的合法操作。

最危险的实现是先 SELECT 判断不存在，再执行业务，最后插入去重记录。两个消费者可以同时读到不存在，随后各自执行一次副作用。数据库唯一约束才是并发竞争的裁决点。对于同一数据库中的修改，可在一个事务里登记 Inbox、修改业务并保存结果；任何一步失败共同回滚，其他事务才能在重试时重新取得执行资格。

遇到唯一键冲突，先查清是哪种情况：相同操作已经完成、操作还在进行、有人用同一个键提交了不同内容，还是其他字段违反了约束。这些情况不能一律报成功，也不能把所有 DataIntegrityViolationException 都当作重复消息忽略。

还要检查事务状态：rollback-only 表示这笔事务已被标记为只能回滚，捕获异常也不会把标记自动撤销。若原事务已经回滚或带有这个标记，应在合适的新事务中读取已提交结果，不能继续假定原事务可以提交成功。

重放是一种受控数据处理任务。先按事件类型、时间段和业务范围确定集合，修复消费者或数据根因，再以原 eventId 重放，记录尝试批次及结果。若需求是重新执行一个合法的新业务动作，应建立新的操作身份并说明因果，不能为了绕过去重随手换 ID。保留期、消费者版本和历史模式兼容共同决定旧事件是否还能被正确理解。

execute 会通过配置的事务管理器取得事务状态，运行回调里的应用代码，然后提交或处理失败。哪些操作能一起提交、一起回滚，取决于这个管理器实际管理的资源。把外部 HTTP 调用、另一个数据库的修改和当前 JDBC 操作都写进回调，不代表它们就自动组成一个事务。先列出真正参与同一事务的操作，才能判断重复消费会不会重复修改业务。

把 Inbox 插入与业务修改放在同一个回调还不够，二者必须实际使用同一事务关联的连接或资源。手工另开连接、错误地切换数据源、把关键修改交给异步线程，都可能绕过当前事务绑定。形式上两行代码挨在一起，不代表持久提交一定共同发生，集成测试要直接核对最终数据。

回调正常返回后仍有提交阶段，磁盘、连接或事务状态可能让提交失败。消费监听器应在真正的事务操作成功结束后 ack，而不是业务回调刚返回就确认。提交结果未知时也不能简单重做非幂等副作用，应利用业务键查询并恢复。教学模型把提交放在 try 回调之后，突出这个常被忽略的阶段。

真实事务模板对不同错误与回滚异常有更细的处理；示例只保留主要分支，不能据此替代框架的异常规则。调用者尤其要避免在回调里 catch 所有异常后返回“成功”，这样事务管理器可能无法知道应回滚。若业务决定只读已有结果，必须先证明冲突记录已经完成，而不是用吞异常实现表面上的幂等。

维护一个非负 long 余额。apply(id,delta) 首次调用应用增减并保存本次结果；相同 ID 与相同 delta 返回原结果，不再次修改余额；同 ID 不同 delta、余额不足或溢出均拒绝。每个失败操作不留下已完成记录。

用 Map 把幂等键映射为不可变回执，回执保存 delta 与当时成功后的余额。先查回执：存在且 delta 相等就返回原结果，存在但不相等则报告冲突。重复操作的返回值可能与当前余额不同，例如后来已有另一笔扣减，仍应返回当初那次操作的结果，才能让重试获得稳定响应。

不存在回执时计算 nextBalance，但在改变任何状态前完成溢出和非负校验。Math.addExact 会在 long 溢出时抛出异常，避免一个很大的正数绕成负数后被错误解释。校验失败时余额和回执都保持原样；校验通过才创建回执并更新状态，构造一个清晰的状态转移点。

同步锁覆盖检查、计算、登记和余额更新，使多个线程不能基于同一旧状态同时推进。本模型只证明单进程中正常内存执行条件下的规则，不能抵抗进程断电或多个实例各有一份 Map。生产必须把相同不变量映射到数据库事务与唯一约束，而不是把 synchronized 当成跨机器互斥。

单次只访问一个 Map 键并进行固定次数整数运算；字符串键散列和比较仍依赖键长度。保存原回执使状态随唯一事件数增长，不能宣称去重是恒定空间。

去重记录保留期必须覆盖消息保留、死信驻留、备份恢复和人工重放的最大合理窗口。若消息能重放三个月而去重键一天后删除，旧事件第二天就可能再次生效。可以按业务生命周期归档完成记录，保留必要摘要与结果，避免无限增长；清理规则应写成可审查的业务策略，而不是任意 TTL。布隆过滤器可减少部分查询，但因存在假阳性，不能单独作为“不执行业务”的唯一裁决。

Outbox 和 Inbox 分别照顾消息的发送端和接收端。发送端在同一事务里保存业务数据和待发消息，投递任务发送后再记录结果；如果发送成功却没记下结果，后续重试就可能再次发送，所以接收端仍要防重复。接收端把业务修改和“已经处理过”的 Inbox 记录一起提交，避免重复生效。它们解决的是各自数据库里两类记录如何一起保存，网络调用结果暂时无法确定的问题仍然存在。

重放应先做范围统计和样本验证，限制并发及下游负载，并记录原事件、重放批次、消费者版本与处理结果。只比较“队列读了多少条”不足以核对业务，应该检查唯一事实数、重复数、内容冲突数与最终状态差异。失败数据修复后也要保留原始事件证据，避免覆盖历史让问题无法解释。