数据工程面试：如何设计 DynamoDB TransactWriteItems 的幂等与重试？
题干与适用场景
订单服务需要在一次业务操作中创建订单、扣减库存并写入账本。网络超时可能发生在 DynamoDB 已提交之后，客户端会再次发送请求。请使用 TransactWriteItems 设计原子写入、条件检查、幂等重试和对账流程，并说明事务的容量成本及区域边界。
面试官考察什么
- 能否区分 DynamoDB 事务的原子提交、条件失败和网络未知结果。
- 能否正确使用
ClientRequestToken、业务幂等键和条件表达式。 - 能否解释事务读写会带来的额外容量消耗、限制与热点风险。
- 能否把重试、补偿、对账、监控和跨区域一致性边界串成完整方案。
回答前要澄清的问题
- 订单、库存和账本是否都在同一 AWS Region 和同一账户边界内？
- 库存扣减是否允许超卖，账本是否必须追加不可变记录？
- 客户端超时后能否查询业务幂等键的最终状态？
- 重试调用是否可能跨越 token 的有效窗口？
- 是否需要跨区域灾备写入，还是只要求单区域原子性？
30 秒回答框架
我会为每个业务操作生成稳定的幂等键，并在同一 Region 用 TransactWriteItems 把订单、库存条件扣减和账本写入放在一个原子事务中。请求带 ClientRequestToken，服务端保存业务状态并通过条件表达式防止重复扣减；超时先查询业务键，再按可判断的错误重试。监控事务冲突、条件失败、容量消耗和未知结果，跨区域场景改用事件和对账，因为该事务的原子边界不跨 Region。
分步骤深入解答
第一步：定义业务不变量
写清楚“订单创建成功时库存必须减少一次，账本必须存在一次”的不变量。订单和账本记录使用同一个 operationId，库存项用条件表达式保证 available >= quantity。不要用客户端时间戳作为唯一键，因为重试和时钟偏差会造成重复业务操作。
第二步：组合事务动作
在一个 TransactWriteItems 请求中组合 Put、Update、Delete 和 ConditionCheck。订单 Put 要求订单键不存在，库存 Update 同时检查版本或可用量，账本 Put 使用 operationId 作为唯一键。一个事务中不能对同一项重复操作，动作数量和请求大小也要符合 API 限制。
第三步：设计两层幂等
ClientRequestToken 让相同事务请求在 token 有效窗口内可安全重试；业务幂等键则持久化在订单和账本中，覆盖更长生命周期。两者必须对应同一个业务操作，不能每次重试都生成新 token。超过 token 窗口后，先读取业务状态，再决定是否重建事务。
第四步：区分失败与未知结果
条件冲突、容量不足或校验失败通常表示事务未按预期提交，可以按错误类型退避或返回业务失败。连接在提交后断开属于未知结果，不能立即执行反向扣库存；应先按 operationId 读取订单、库存版本和账本，再通过状态机决定重试或对账。
第五步：计算成本和热点
事务会对每个项目执行准备和提交阶段的底层读写，因此容量消耗高于普通单项写入。按最大项大小、事务并发和重试放大估算吞吐，并为库存热点分片或改用预扣库存队列。不要只用平均 WCU 计算峰值，条件失败和冲突也会消耗容量与延迟预算。
第六步：处理跨区域需求
该事务的原子性适用于调用所在 Region 的事务边界。若订单在主 Region、分析或备份在其他 Region，提交后发布带 operationId 的事件，消费者按幂等键写入，并用对账任务发现缺失或重复。跨区域复制延迟期间，读模型不能被当作事务提交的即时证明。
第七步：观测与恢复
记录事务成功率、条件失败、冲突、限流、重试次数、未知结果、每个表的容量消耗和端到端延迟。把订单状态分为 PENDING、COMMITTED、RECONCILING 和 FAILED，定时任务扫描未知状态并补齐账本或生成人工队列。告警应按 operationId 串联请求日志、表项和事件。
高质量示范回答
我会为一次下单生成稳定的 operationId，在同一 Region 的 TransactWriteItems 中创建订单、条件扣减库存并写入以该 ID 为键的账本记录。订单写入要求键不存在，库存更新检查版本和 available >= quantity，账本写入天然去重；请求同时携带稳定的 ClientRequestToken。条件失败直接返回可解释的业务错误，提交后的网络超时先读取 operationId 对应的三类记录，不能盲目反向写入。容量按事务准备与提交的额外读写、热点和重试放大估算。跨区域同步使用带幂等键的事件和对账，不宣称跨 Region 原子性；监控冲突、容量、未知结果和状态机恢复时间。
常见错误
- 把网络超时当成事务一定失败，立即执行反向库存操作。
- 每次重试都生成新的业务键，导致重复订单或账本。
- 只依赖
ClientRequestToken，忽略长期业务幂等记录。 - 忽略条件冲突、事务大小和事务读写的额外容量成本。
- 把跨 Region 复制或全局表读到的数据当成事务提交证明。
- 没有未知状态扫描和对账机制，依赖人工查日志。
追问及应对
追问一：ClientRequestToken 能永久保证幂等吗？
不能。它只覆盖 API 规定的有效窗口。长期幂等必须由订单、账本或独立操作表保存业务键和最终状态。
追问二：库存条件失败时要不要重试？
若原因是库存不足，重试不会改变结论，应返回业务失败；若是临时冲突或限流，可退避重试，但必须复用同一业务操作键并限制次数。
追问三：提交后超时如何判断结果？
读取 operationId 对应的订单、库存版本和账本记录。三者一致表示已提交；部分可见或状态不一致时进入 RECONCILING，由对账流程决定补写或人工处理。
追问四：为什么不把跨区域写入也放进一个事务？
该 API 的原子边界不覆盖多个 Region。跨区域需求应使用事件、幂等消费者和对账，明确最终一致窗口与降级策略。
追问五：事务冲突如何定位？
记录 operationId、涉及表键、条件版本和重试次数，按热点键聚合冲突率。若单库存项持续冲突，应分片、预扣或改成队列化库存分配。
追问六：如何测试未知结果路径？
在服务端确认提交后主动丢弃响应，模拟客户端超时；随后验证查询、重试、状态机、事件去重和对账结果，确保不会重复扣库存或写账本。