事务一致性最容易出问题的地方，往往不是数据库执行失败，而是系统已经执行了一部分、调用方却不知道执行到哪里。一次支付请求超时，数据库可能已经提交；一条消息消费报错，业务动作可能已经完成；一个补偿任务看似修复了订单，却可能再次扣减库存。架构师真正要自查的，不是“有没有回滚”，而是异常发生后，系统能否识别真实状态、避免重复副作用，并最终证明业务已经恢复。

数据库存：架构师自查表：事务一致性最容易出现的异常恢复难

一、先讲核心结论：一致性难在“未知状态”，不难在“报错”

1. 正常失败通常不是最危险的失败

如果数据库在事务提交前明确返回约束冲突、死锁回滚或业务校验失败，处理反而相对简单。调用方知道本次操作没有成功，可以返回失败，也可以在满足条件时重新发起。

真正危险的是结果未知。客户端收到超时、连接断开或网关 502，并不能证明数据库事务没有提交。服务端可能已经完成写入，只是在返回响应之前进程崩溃，或者网络链路已经断开。

我在做故障复盘时，通常会先把“失败”拆成三种状态：明确失败、明确成功、结果未知。很多重复扣款、重复创建、状态覆盖，都不是业务代码完全错误，而是系统把第三种状态误判成了第一种状态。

这张表里最应该被单独设计的是“结果未知”。如果系统只为成功和失败设计分支，却没有未知状态的查询、挂起、对账和人工兜底，异常恢复迟早会依赖猜测。

2. 事务边界决定了你能不能回滚

数据库事务只能保证它所覆盖资源的原子性。一个订单流程可能同时涉及订单表、库存表、支付服务、消息队列、缓存和搜索索引。即使订单表与库存表处于同一个本地事务，支付接口和消息投递仍然可能在事务边界之外。

因此，“事务回滚”不是一个可以覆盖全链路的万能动作。数据库回滚能够撤销数据库内尚未提交的变更，却不能撤销已经发出的短信、已经完成的第三方扣款，也不能让已经被下游消费的事件自动消失。

我的判断原则很简单：先画资源边界，再讨论一致性方案；先确认哪些动作不可逆，再决定是回滚、重试还是补偿。没有这一步，直接讨论分布式事务、消息事务或最终一致性，通常只是在堆技术名词。

3. 最终一致性必须具备“收敛证明”

“最终一致”不是一句让系统稍后自行恢复的承诺。一个真正可运行的最终一致方案，至少要说明四件事：谁发现异常、谁触发恢复、恢复动作能否重复执行、什么指标证明系统已经收敛。

例如，订单已支付但订单状态仍是待支付。系统需要有支付结果查询或对账任务发现它，需要有状态推进逻辑修复它，需要保证重复回调不会重复发货，还需要设置超过一定时间仍未收敛的告警。

如果没有异常记录、补偿任务和对账规则，所谓最终一致性只是把错误从主流程隐藏到了后台。

二、背景和真实场景：一笔超时请求是怎样变成数据事故的

1. 支付请求超时，不等于支付失败

假设用户点击支付，应用服务向支付服务发起请求。支付服务完成扣款并写入支付结果，随后应用服务准备返回成功响应，却在此时遭遇网络断开。

用户看到的是“支付超时”，于是再次点击支付。第二次请求如果没有使用业务幂等号，系统可能再次调用扣款接口；即使支付服务本身没有重复扣款，订单系统也可能创建第二笔支付单、发送两次支付成功消息，甚至触发两次发货。

这里至少存在四个不同的状态：支付请求是否提交、支付资金是否扣除、订单状态是否更新、支付成功事件是否被消费。把它们压缩成一个“支付成功或失败”字段，是排查困难的根源。

2. 订单、库存和消息之间的断点

另一个常见场景是下单。服务先在数据库事务中创建订单并扣减库存，事务提交后再向消息队列发送“订单已创建”事件。若服务在提交完成和发送消息之间宕机，订单与库存已经生效，履约、积分或通知系统却完全不知道这笔订单。

反过来，如果先发送消息再提交数据库事务，消费者可能先收到订单事件，但随后数据库事务回滚。下游系统看到了一笔不存在的订单，需要额外处理撤销或等待确认。

这两种顺序都不是天然正确。先写库后发消息的主要风险是消息丢失，先发消息后写库的主要风险是下游提前消费无效事件。架构设计要做的是让中间状态可记录、可重试、可查询，而不是迷信某一种固定顺序。

3. 消费成功但确认失败，会制造“幽灵重试”

消息消费者收到扣库存事件，完成库存扣减后向消息系统发送确认。若确认请求丢失，消息系统会认为消费失败并再次投递。

如果消费者把“收到消息”作为幂等依据，却没有把业务处理结果持久化，第二次消费仍可能再次执行扣减。更隐蔽的情况是，去重记录写入成功但业务更新失败，后续重试被错误拦截，最终形成“消息没有丢，业务也没有完成”的假成功。

所以消费幂等不能只看消息 ID。实际设计中，我会同时检查业务状态、唯一约束和处理记录，确保“记录已处理”与“业务结果已生效”之间不会出现不可解释的裂缝。

4. 缓存和搜索索引通常不值得强行纳入强事务

订单主表已经更新，但缓存刷新失败，用户短时间内仍看到旧状态；搜索索引更新延迟，后台明明存在商品，搜索结果却暂时查不到。这类不一致未必需要分布式强一致事务。

如果业务允许几秒或几分钟延迟，更合理的做法通常是主库作为事实来源，缓存通过失效或异步刷新修复，索引通过事件重放或全量校正恢复。为了消灭所有短暂不一致而引入跨系统锁和同步提交，可能会把一个可接受的读延迟问题，升级成全链路可用性问题。

三、常见误区：看似在恢复，实际上在放大故障

1. 把异常响应直接当成回滚结果

HTTP 500、网关超时、RPC 连接断开，都只是调用链观测到的通信结果，不是数据库事务日志。调用方无法仅凭这些信号判断服务端是否提交。

在接口设计上，提交类操作最好返回业务请求号或幂等号，并提供结果查询接口。对于结果未知的请求，客户端可以进入查询状态，而不是立即执行一个全新的业务动作。

如果暂时无法提供查询接口，至少要让同一业务请求携带稳定的幂等键。这样即使用户重试，服务端也能返回第一次操作的最终结果，而不是再次产生副作用。

2. 所有失败都无脑重试

重试适合处理临时性故障，例如连接池短暂耗尽、瞬时网络抖动或某些可恢复的依赖超时。但参数错误、库存不足、账户冻结、唯一键冲突等业务失败，重试不会让结果变好。

更重要的是，外部调用超时不能简单归为“可重试”。如果外部系统已经扣款，本地重试可能造成重复扣款；如果外部系统支持结果查询，应先查询；如果不支持查询，则需要通过对账、冲正或人工流程处理。

我通常把重试决策拆成三个问题：

• 这次失败是业务拒绝，还是基础设施暂时不可用？
• 上一次副作用是否可能已经发生？
• 重复执行是否有幂等保证，或者是否存在安全的查询路径？

3. 只加一个幂等字段，就认为幂等完成了

幂等键的存在不等于幂等逻辑成立。需要明确幂等键由谁生成、覆盖哪个业务动作、保存多长时间、是否有唯一约束，以及并发请求同时到达时谁先建立记录。

例如，订单入口使用 request_id 去重，但支付回调、发券、扣库存仍使用各自的内部流程。如果同一订单经过重试后进入这些环节，每个副作用仍然可能重复发生。

幂等应覆盖“业务动作”，而不是只覆盖“接口入口”。一次订单支付可能至少需要分别保证支付回调幂等、订单状态推进幂等、发货指令幂等和通知发送幂等。

4. 只做生产端可靠，不做消费端幂等

可靠消息只能降低消息丢失风险，不能自动消除重复消费。很多消息系统为了提高投递可靠性，允许消息至少一次到达，因此消费者必须假设同一事件会重复出现。

消费端常见的错误是使用“收到消息即写入已消费表”的方式去重，却没有将已消费记录和业务变更放在同一个可控事务边界内。若两者分离，就会出现记录写成功、业务写失败的情况。

更稳妥的处理方式是让业务状态更新和消费记录具备一致的提交关系，或者通过业务状态机判断是否已经完成。对于外部不可回滚动作，还要设计结果查询与补偿。

5. 只记录错误日志，不记录恢复状态

“调用支付接口超时”这条日志对研发有帮助，但对恢复系统远远不够。恢复任务还需要知道订单号、请求幂等号、外部交易号、当前订单状态、上次重试时间、已重试次数和最后一次结果。

如果日志与业务记录无法关联，故障发生后只能依赖人工搜索文本。系统规模一旦扩大，人工排查时间会迅速超过业务可接受窗口。

6. 认为“最终一致”就是“最终一定一致”

最终一致性成立的前提是系统存在持续推进机制。任务没有扫描范围、没有失败上限、没有死信处理、没有对账窗口，或者补偿动作本身不幂等，都可能让异常永久停留在中间状态。

四、专业判断逻辑：先识别状态，再选择恢复动作

1. 用四个问题判断异常是否可恢复

我在设计评审中不会先问“要不要上分布式事务”，而会先让团队回答四个问题。这四个问题能把大多数异常恢复方案从概念讨论拉回到可执行层面。

1. 结果是否已知？ 是明确成功、明确失败，还是状态未知？
2. 动作是否幂等？ 重复执行会不会造成新的业务副作用？
3. 结果是否可查询？ 能否通过业务号、外部交易号或对账接口查到最终结果？
4. 动作是否可逆？ 不能回滚时，是否存在语义明确的补偿动作？

如果结果明确失败且没有事务外副作用，可以结束或重试；如果结果未知但可查询，应优先查询；如果结果未知、不可查询且动作不可幂等，就不能依靠自动重试，必须进入对账或人工处理。

2. 一个实用的恢复决策表

3. 不要把“补偿”理解成简单反向操作

补偿不是把原 SQL 反向执行一遍。原动作可能已经触发了其他副作用，也可能因为业务状态变化而无法直接逆转。

例如，库存扣减后订单取消，补偿动作不是简单执行一次库存加一。系统还要确认这次库存扣减是否已经被履约锁定、是否已经形成出库单、是否存在重复补偿。正确的补偿通常是一条有状态、有原因、有唯一业务编号的业务指令。

支付场景更不能把补偿等同于退款。扣款结果未知时，首先要查询支付状态；只有确认已扣款且订单无法继续履约，才进入退款或冲正流程。

4. 用状态机限制恢复动作的边界

状态机的价值不只是让代码更整齐，而是防止迟到的消息和重复的补偿覆盖正确状态。订单已经完成，不应被一条延迟到达的“支付失败”消息改回待支付；已经退款的订单，也不应被旧的支付成功回调再次推进到可发货。

每次状态转换都应该有前置状态限制、事件来源和版本控制。对于并发更新，可以通过版本号、条件更新或数据库约束避免旧事件覆盖新状态。

UPDATE orders
SET status = 'PAID',

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE order_id = ?

AND status = 'PENDING_PAYMENT'

AND version = ?;

这段伪 SQL 的关键不在语法，而在条件更新：只有订单仍处于待支付状态，且版本没有变化时，支付成功事件才允许推进。更新行数为 0 时，系统不能直接当作失败，而要进一步判断订单是否已经被其他流程推进。

五、架构师自查表：设计评审时必须逐项问清楚

1. 事务边界自查

• 一个本地事务具体覆盖哪些表和数据约束？
• 事务提交后还有哪些动作必须执行？
• 哪些动作属于外部系统，无法由本地数据库回滚？
• 事务超时后，调用方能否查询真实提交结果？
• 连接断开时，服务端是否仍可能继续执行？

如果团队无法在一张图上标出事务边界，说明当前讨论的一致性仍停留在抽象层。尤其要警惕“一个接口看起来完成了整个业务”，但内部实际跨越多个服务、多个数据库和多次异步投递。

2. 幂等性自查

• 业务请求是否有稳定且可追踪的幂等键？
• 幂等键是否有数据库唯一约束或可靠存储？
• 并发请求同时到达时，是否只有一个请求能够建立业务记录？
• 幂等记录保留时间是否覆盖最大重试周期和对账周期？
• 下游发券、扣款、扣库存、发货等副作用是否分别幂等？

一个容易漏掉的细节是幂等键生命周期。幂等记录过早删除，历史请求重放时可能重新执行；记录永久保留，则会增加存储和清理成本。生命周期应按照业务最大重试窗口、账务对账周期和客服处理周期共同确定。

3. 消息链路自查

• 本地事务提交后，消息是否可能丢失？
• 消息发送成功但发送结果未知时，如何处理？
• 消费者处理成功但确认失败时，是否可以安全重复消费？
• 消息是否可能乱序到达？状态机能否拒绝迟到事件？
• 重试是否有退避、上限和死信处理？

对于数据库和消息需要联动的场景，常见做法包括 Outbox、可靠事件表或具备事务语义的消息机制。选择时要评估扫描延迟、重复发送、事件表膨胀、消息积压和运维复杂度，不能只看“能不能保证不丢”。

4. 补偿和对账自查

• 每一种中间状态是否都有明确的超时阈值？
• 补偿任务是否可以重复运行而不制造新副作用？
• 自动补偿失败后是否会进入死信或人工队列？
• 对账任务使用什么事实来源？
• 发现差异后，系统是否能够生成可审计的处理记录？

对账不是财务团队的专属工作。在分布式系统中，对账是恢复链路的最后验证环节。没有对账，系统只能知道“任务执行过”，却不知道订单、支付、库存和履约是否真的达成业务一致。

5. 可观测性自查

六、具体案例和数据观察：订单支付链路如何避免重复副作用

1. 先把一个支付流程拆成可观察的事实

下面以一个抽象的支付，订单，履约流程为例。它不对应某家企业的生产数据，而是我在架构评审中常用的情景模型，用来说明状态和动作如何分离。

用户提交订单后，系统先创建订单和支付单。支付服务返回成功后，订单状态推进为已支付，同时写入支付成功事件。履约服务消费事件并创建发货任务。每一个环节都要记录自己的状态，不应只依赖订单表里的一个 status 字段。

2. 场景一：支付接口超时

支付接口超时后，系统不能马上新建支付单。第一步是用原支付请求号查询支付服务；若查询到成功，则把本地支付单推进为成功；若查询到失败，则允许用户重新支付；若仍然无法查询，则把支付单置为“结果待确认”，交给对账任务。

这里的“结果待确认”不是失败，也不是成功。它是一个明确的业务状态，意味着系统暂时不能继续发货，但也不能把支付动作当作从未发生。

如果系统把它直接标记为失败，用户可能再次支付；如果直接标记为成功，可能在实际未扣款时提前发货。挂起状态的价值，是把不确定性显式化，而不是让不确定性偷偷进入自动流程。

3. 场景二：支付成功，但事件发送失败

订单和支付单已经在本地事务中更新，事件发送却由于消息服务不可用失败。此时不能回滚已经确认的支付结果，也不能让订单回到待支付状态。正确动作应是记录待发送事件，并由可靠投递任务继续发送。

事件发送任务必须允许重复执行。发送者可能不知道上一次发送是否成功，因此同一事件可能被发送两次。下游消费者需要以 event_id 或业务动作号去重，同时用订单状态判断事件是否仍然有效。

4. 场景三：履约任务已经创建，但消费确认失败

履约服务消费支付成功事件，创建发货任务后确认失败，消息再次到达。第二次消费不应该再次创建发货任务，而应通过“订单号加履约动作类型”的唯一约束找到原任务，返回已存在结果。

INSERT INTO fulfillment_task
(order_id, action_type, status, created_at)
VALUES
(?, 'CREATE_SHIPMENT', 'PENDING', CURRENT_TIMESTAMP)
ON CONFLICT (order_id, action_type)
DO NOTHING;

不同数据库的冲突语法并不相同，上面的代码只用于表达设计意图。真正重要的是：业务动作有唯一身份，重复消费不会产生第二个有效任务。

5. 一组用于评审的情景模拟数据

假设一个日均 100 万笔请求的交易系统中，基础设施异常比例只有千分之一，也意味着每天约有 1000 笔请求进入异常处理。若其中 30% 属于结果未知，便有约 300 笔请求不能通过普通失败重试解决。

如果这 300 笔请求中有 10% 会产生重复副作用，每天就可能出现约 30 笔重复扣款、重复发券或重复创建任务。这个数量看起来不大，但一旦涉及资金和库存，人工处理成本、客户投诉和对账压力都会远高于普通接口错误。

6. 这些数据应该怎样使用

上面的数字是情景模拟，不是行业基准，更不能被包装成某个系统的真实故障率。它的用途是帮助架构师做容量和人力预算：异常处理任务需要处理多少记录，补偿窗口多长，人工队列每天可能增加多少条，数据库和消息系统是否承受得住重放流量。

在真实系统中，我建议至少统计以下数据，而不是只看接口成功率：

• 结果未知请求占全部异常请求的比例；
• 重试后仍未收敛的业务单数量；
• 重复消费被拦截的次数；
• 补偿任务成功率与平均完成时间；
• 超过阈值仍处于中间状态的记录数；
• 对账发现的差异数量及平均修复时长。

接口成功率为 99.99%，并不代表业务一致性风险很低。如果剩下的 0.01% 都集中在支付、库存和履约的关键断点，系统依然可能产生严重事故。

七、不同情况下的行动建议：不要用同一种恢复方式处理所有异常

1. 单数据库、单服务、事务边界清晰

这类场景优先使用本地事务、数据库约束和合理的隔离级别。不要因为看到“一致性”三个字，就立刻引入消息队列或分布式事务。

重点检查事务是否覆盖完整业务约束，例如余额扣减与余额流水是否同事务，订单主表与明细表是否同事务，唯一性是否由数据库约束兜底，而不是只依赖应用层先查后写。

• 将关键业务约束下沉到数据库唯一约束、检查约束或条件更新。
• 避免在事务中执行长时间外部调用。
• 缩短事务持有锁的时间，减少死锁和锁等待。
• 为超时和死锁设置明确的重试分类。
• 记录事务关联的业务号，方便后续排查。

2. 数据库与消息队列必须联动

如果数据库提交成功后必须发送消息，应考虑可靠事件表或 Outbox 模式。核心做法是把业务变更和待发送事件一起写入同一个本地事务，再由独立投递器扫描并发送。

这种方案不能让消息系统和数据库真正同时提交，但它把“数据库已变更、消息完全没有记录”的不可见断点，转化成“事件已记录、尚未投递”的可恢复状态。

代价也必须提前接受：事件表需要清理，投递器需要限速，重复发送需要消费者幂等，消息积压需要告警。它提升的是可恢复性，不是免费获得全局强一致。

3. 跨服务调用涉及资金、库存或权益

优先设计状态查询、业务幂等和对账机制。资金类操作通常不能只依赖客户端回调，库存类操作不能只依赖缓存数量，权益发放不能只依赖消息“看起来发送成功”。

对于外部接口超时，应先确认对方是否提供按业务号查询的接口。如果没有查询能力，至少要保留请求报文、外部响应、交易号和时间线，为后续对账或人工处理提供依据。

4. 读模型、缓存和搜索索引允许延迟

把主数据库作为事实来源，异步刷新缓存或索引。更新失败后使用重试、事件重放、定期校正或全量重建，而不是把所有读写系统绑进一个长事务。

但“允许延迟”要有明确边界。应该定义最大可接受延迟，例如普通商品搜索允许 5 分钟内收敛，订单支付状态页面允许几十秒内刷新，而库存可售数量可能需要更严格的实时校验。

5. 需要人工介入的异常不要伪装成自动化

当外部结果不可查询、动作不可逆、金额较大或业务状态相互矛盾时，自动重试可能比人工处理更危险。此时应冻结后续副作用，进入人工队列，并保留完整的处理权限、原因和审计记录。

人工介入不是架构失败。真正的问题是系统没有定义人工介入的入口、责任人和完成标准。一个可控的人工流程，往往比一个无法解释的无限补偿任务更可靠。

八、不同方案的取舍：强一致、最终一致与业务补偿怎么选

1. 本地事务：边界内最可靠，边界外无能为力

本地事务的优点是语义清晰、故障恢复成熟、开发和运维成本较低。对于同一数据库内的订单、明细、余额流水等数据，它通常是第一选择。

它的短板也很明确：无法直接覆盖外部支付、消息、缓存和其他数据库。若业务流程天然跨系统，就必须增加事件记录、状态机、补偿或对账。

2. 分布式事务：强约束换来复杂协调

分布式事务适合对跨资源原子性要求非常高、参与者数量可控、技术栈和运维能力较成熟的场景。但它通常会增加锁持有、协调器依赖、超时处理和故障排查复杂度。

如果业务能够接受秒级或分钟级收敛，却为了消灭短暂不一致而把所有调用放进同步协调，系统可能牺牲可用性和吞吐量。强一致不是越强越好，而是要与业务损失相匹配。

3. 最终一致加补偿：可用性更好，但运营责任更重

最终一致方案可以把多个系统解耦，允许局部故障，不必让所有服务同时在线。它更适合订单履约、通知、积分、搜索索引等可以异步完成的流程。

代价是系统必须拥有异常监控、重试调度、死信处理、对账和人工运营能力。没有这些配套，最终一致只是把技术复杂度转移到了数据运营和客户服务。

4. 直接同步调用：简单直观，但容易形成级联故障

同步调用的优势是流程容易理解，状态也更快反馈给用户。问题在于，任何一个下游超时都可能拖长主事务，连接池、线程池和数据库锁会出现连锁占用。

适合不适合使用同步调用，关键看下游动作是否必须在当前请求内完成，以及超时后是否能够确认结果。对于支付结果确认这类动作，可以同步发起查询，但不要把所有后续履约都阻塞在同一个请求里。

九、如何验证恢复真的有效：从日志证明走向业务证明

1. 先定义“恢复完成”的业务条件

恢复任务执行成功，不等于业务已经恢复。比如消息补发成功，只能证明事件重新进入消息系统；只有下游消费成功、业务状态推进、重复副作用被阻止，订单链路才算真正完成。

每一种异常都应定义完成条件。支付异常的完成条件可能是本地支付状态与外部支付状态一致；库存异常的完成条件可能是库存流水、可用库存和订单状态相互匹配；索引异常的完成条件可能是索引版本追上主库版本。

2. 建立上下游对账，而不是只查单表

对账应围绕业务事实建立。订单表只能说明订单服务保存了什么，支付表只能说明支付服务记录了什么，真正需要验证的是两者之间是否符合业务规则。

• 订单为已支付时，是否存在金额相等且状态成功的支付记录？
• 支付成功时，是否存在对应订单，且订单没有被错误取消？
• 库存扣减流水之和，是否与库存余额和锁定量一致？
• 已支付订单是否最终生成履约任务？
• 已完成履约是否出现重复发货指令？

对账规则应记录差异类型，而不是只输出“数量不一致”。差异类型越明确，自动补偿越容易，人工处理也越快。

3. 监控中最值得增加的五个指标

其中，重复动作拦截数不应被简单当作系统异常。它有时反而说明幂等机制正在发挥作用。更有价值的是观察重复拦截是否突然上升，因为这通常意味着网络超时、消息重复或客户端重试正在发生变化。

4. 故障演练必须覆盖提交后的断点

很多测试只验证数据库事务执行失败，却没有测试提交成功后的进程退出。后者更接近生产中最难处理的未知状态。

我建议至少演练以下断点：

1. 数据库提交成功后，服务在返回响应前退出。
2. 本地事务提交成功后，事件记录已经写入但消息发送器被停止。
3. 消息已被消费者处理，但确认请求被模拟丢失。
4. 外部支付返回超时，但通过后台查询发现实际已扣款。
5. 补偿任务执行到一半进程退出，再次启动后重复扫描。
6. 迟到事件覆盖新状态，验证状态机和版本条件是否生效。

演练的验收标准不能只看“错误有没有被记录”，而要看：是否产生重复副作用、是否能查询真实状态、是否能自动恢复、是否进入正确的人工队列，以及恢复后对账是否通过。

十、落地实施路线：先补可见性，再补自动化

1. 第一阶段：建立业务时间线

先不要急着重构所有事务。选择支付、库存或订单履约中最容易出问题的一条链路，为每个动作补齐业务请求号、幂等键、事件编号、外部交易号和状态变更时间。

目标是让排查人员能够回答：请求何时进入、事务何时提交、事件何时生成、消息何时消费、补偿何时执行。没有时间线，后续所有自动化恢复都缺少可信输入。

2. 第二阶段：显式区分成功、失败和未知

在数据模型中增加待确认、补偿中、补偿失败或人工待处理等状态。不要用一个失败字段承载所有异常，也不要让异常记录只存在于日志中。

状态越明确，重试策略越容易分层。明确失败可以快速结束，明确成功可以推进后续流程，未知状态则进入查询、对账或人工处理。

3. 第三阶段：为副作用动作补齐幂等

从最贵、最危险、最不可逆的动作开始，例如扣款、发券、库存扣减和发货。为每个动作定义唯一业务身份，并验证并发请求和重复消息下的行为。

不要只测试连续两次正常请求。必须测试第一次请求在服务端已完成、客户端未收到响应时，第二次请求是否能够返回第一次结果。

4. 第四阶段：建设可靠事件与补偿任务

把数据库和消息之间的断点显式化。可靠事件表应至少包含事件类型、业务号、发送状态、重试次数、下次重试时间、最后错误和创建时间。

补偿任务要有退避策略和上限。连续失败的记录应进入死信或人工队列，不应在主库中无限循环。补偿任务还要限流，避免故障恢复时对下游造成第二次冲击。

5. 第五阶段：用对账和演练验证收敛

当自动恢复机制上线后，最重要的不是补偿成功数量，而是异常是否在规定时间内收敛，以及是否出现重复副作用。对账和故障演练应进入日常发布与复盘流程。

十一、发布前的最终自查清单

1. 业务设计检查

• 是否定义了哪些一致性必须强保证，哪些可以延迟？
• 是否列出了所有不可逆副作用？
• 每个异常状态是否都有结束条件？
• 结果未知时，用户看到的提示是否会诱导重复操作？
• 取消、退款、补发和冲正是否都有明确业务语义？

2. 数据库设计检查

• 关键唯一性是否由数据库约束保证？
• 状态推进是否使用条件更新或版本控制？
• 事务范围是否过大，是否包含慢速外部调用？
• 重试是否可能遇到锁等待、死锁或唯一键冲突？
• 事件表、幂等表和补偿表是否有清理与归档策略？

3. 消息和任务检查

• 生产端是否能发现数据库已提交但消息未发送？
• 消费端是否能承受重复消息？
• 消息乱序时是否会覆盖新状态？
• 重试是否采用退避并设置最大次数？
• 死信是否有人负责处理，处理结果是否可审计？

4. 运行与复盘检查

• 是否能按业务号还原完整时间线？
• 是否监控结果未知率和中间状态积压？
• 是否有跨系统对账，而不是只查单个服务数据库？
• 是否定期模拟提交后断网、消费确认失败和外部超时？
• 是否明确自动恢复失败后的责任人和处理时限？

十二、结语：真正成熟的一致性，不是永远不出错，而是出错后可证明地恢复

1. 事务一致性的判断标准应该改变

很多团队把一致性设计成正常流程图：开始、提交、成功。生产系统真正需要的是另一张图：提交前失败、提交后超时、消息丢失、消息重复、外部结果未知、补偿失败和人工介入。

如果这张异常图没有画出来，系统并不是没有异常，只是异常发生后没人知道该怎么判断。

2. 架构师最应该盯住的不是技术名词

本地事务、分布式事务、Outbox、消息重试、状态机和补偿，都是实现手段。真正决定系统可靠性的，是以下五个问题能否被明确回答：

1. 真实状态如何确认？
2. 重复动作如何阻止？
3. 不可逆动作如何补偿？
4. 异常如何被发现并推动收敛？
5. 最终结果如何通过对账证明？

这五个问题中，任何一个没有答案，系统就可能在网络抖动、进程退出、消息重复或第三方超时后陷入不可解释状态。

3. 下一步怎么做

建议从一条涉及订单、支付、库存或履约的真实链路开始，画出正常路径和全部异常断点。然后为每个断点补上四列信息：真实状态、可执行动作、重复风险、完成证明。

第一周先补业务号和状态时间线；第二周补幂等和条件更新；第三周补可靠事件、重试和死信；第四周做一次提交后断网与消费确认失败演练。不要一开始追求全链路强一致，先让系统能够看见异常、控制副作用、推动恢复并证明收敛。

事务一致性最容易出现的异常恢复难，本质上不是数据库不会回滚，而是系统没有为“已经做了一半、结果暂时未知”的世界建立模型。能把未知状态显式化，并为它设计查询、重试、补偿、对账和人工兜底，才是架构师真正完成了一致性设计。

免费注册

咨询方案

扫码咨询方案