事务发件箱与外部副作用

直接写数据库再发消息，有一个“数据已变，进程还没来得及发”的空档；先发消息再写数据库，则有“外面已经行动，本地却回滚”的相反空档。Outbox把待办内容与业务一起存下，关闭的是发送意图会不会被遗忘的问题。

中继与接收者之间仍是一轮结果可能未知的RPC理路RPC结果判定与重试的不确定性RPC outcome uncertainty · Unknown outcome · Retry semantics为一个逻辑请求维护待定、成功、明确失败与结果未知状态，用不可区分轨迹解释响应丢失、重连和deadline后仍可能执行。。接收者做完之后确认丢了，中继就不知道该停止还是再试。记录“已经发过”不是记录“对方已持久完成”；无论把它放在发送前还是发送后，都要面对另一个崩溃窗口。

一次登记，两次通知尝试 ​

订单库初始没有订单，也没有待发记录。一项原子事务写入order7=CONFIRMED和O[m7]=(warehouse,reserve(7))，提交完成后接口只承诺“订单已登记，通知待处理”，不承诺仓库已经预留。

中继发送m7；仓库预留一件商品并提交，库存从5变4，但确认丢失。中继仍看见m7未交付，于是重发。没有接收去重时，库存可再从4变3；有原子Seen[m7]与预留结果时，第二次只返回原结果，库存保持4。随后中继持久标记m7已交付。

这里两次发送、两次接收都允许发生；受保护的是仓库定义的业务效果。若仓库提交后又调用一个没有去重合同的短信网关，短信仍可能重复，保证不会自动越过这个新边界。

标记前后都可能崩溃 ​

若中继先标记“已完成”，随后发送前崩溃，恢复会跳过m7，通知永久丢失。若在仓库提交后、中继标记前崩溃，恢复重发m7，产生重复投递。这说明只靠发送方的一个布尔标记，无法同时关闭两边独立原子域的窗口。

正确outbox选择保留未确认项目并允许重试，再由接收端幂等或去重处理重复。这里的“最终至少投递一次”还依赖中继持续运行、接收者最终可用、通信重试最终成功以及待发记录不被提前删掉；永久网络中断时只有保存意图的安全保证。

顺序也需另行建立 ​

同一订单先提交m7:CONFIRMED再提交m8:CANCELLED，两个中继并发时可能先送达m8再送m7。Outbox的存在不自动给接收端业务顺序。可按订单键串行投递并等前一项确认，或让接收者按业务版本拒绝旧版本并处理缺口；不能只按全局消息到达时间覆盖状态。

接收者回收Seen[m7]后，极迟的重试仍可能再次预留。因此保留期要覆盖允许重放窗口，或在过期后拒绝旧消息/旧会话；“去重表每天清空一次”不能与永久一次效果承诺同时成立。

可以把整个流程分成三个可观察里程碑：源业务与意图已提交；接收端效果已按其合同提交；源端已记录接收确认。它们通常不是一个原子时刻。若API要承诺第二层，就必须拿到或查询第二层的可靠证据；不能把第一层成功响应改名为“外部付款已完成”。

在复制服务理路状态机复制State machine replication · SMR让多个副本按同一确定顺序执行命令，从而实现容错服务。中，O和业务结果表一样必须随同前缀快照理路Raft快照、日志压缩与安装Raft snapshot installation · Log compaction snapshot · InstallSnapshot以同一前缀的业务状态、请求结果、配置和索引任期构造恢复包，明确稳定发布、后缀保留和旧快照拒绝条件。恢复。新leader可接管中继，旧leader也可能有已发出的请求，因此身份稳定和接收去重仍有用；必要时再用fencing理路Fencing令牌与过期持有者Fencing token · Stale holder fencing · Fencing epoch让资源端原子保存递增代际并拒绝旧持有者，复算暂停后迟到写、激活屏障、同代重复与资源恢复的不同责任。隔离旧中继的其他资源操作。Fencing不会单独识别同一代重复消息。

待发积压为p条、平均payload为c字节时，源端至少保留O(pc)字节，另有索引和结果；接收去重也消耗保留记录。若输入速率长期大于确认速率，p会无界增长，应有背压、配额或明确失败策略。删除已确认记录可以控制空间，但不能以删除为由允许旧身份变成一项新业务。

不可撤销副作用需要更谨慎的承诺：发送邮件、打印、人工处理未必提供可原子验证的业务ID。补偿是另一项后来执行的业务动作，可能失败，也不会让已读邮件“从未发送”。完整服务应公开“已登记/处理中/结果未知/已确认”等实际状态，而不是用复制日志掩盖这些边界。