影院聚合应用：确保HTTP预订成功后数据库更新的设计模式咨询

针对「供应商预订HTTP调用成功，但本地交易数据库更新失败」的一致性问题，以下是几种落地性强的设计模式，直接适配你的业务场景：

1. 补偿事务（TCC - Try-Confirm-Cancel） #

把整个预订流程拆分为三个阶段：

• Try阶段：先在本地数据库初始化交易记录，状态标记为「待确认」，同时调用供应商的预留座位接口（非最终确认预订接口），确保供应商锁定座位但未完成最终预订。
• Confirm阶段：若Try阶段全部成功，调用供应商的确认预订接口完成正式预订，随后更新本地数据库交易状态为「已完成」。
• Cancel阶段：若Confirm阶段中本地数据库更新失败，立即调用供应商的取消预留接口释放锁定座位，同时将本地数据库交易状态改为「已取消」。

核心要点：

• 要求供应商提供可撤销的预留能力，避免单边成功的情况。
• 本地需记录每个阶段的执行状态，方便故障恢复时重试或补偿。
• 确保供应商的Cancel接口具备幂等性，重复调用不会产生异常。

2. 可靠消息最终一致性（基于消息队列） #

引入持久化消息队列做异步解耦，确保本地数据库更新与供应商操作最终一致：

• 第一步：本地数据库初始化交易记录（状态「待处理」），同时向消息队列发送一条「待预订」持久化消息（确保消息不丢失）。
• 第二步：消费端读取消息，调用供应商预订接口。调用成功则发送「预订成功」消息；失败则重试指定次数后标记消息为「失败」，触发人工干预。
• 第三步：消费「预订成功」消息，更新本地数据库交易状态为「已完成」。若更新失败，消息队列自动重试，直到更新成功（需确保数据库更新操作幂等，比如用交易ID作为唯一约束）。

若第一步发送消息失败，直接回滚本地交易，用户重新发起预订即可。该方案适合供应商接口支持幂等、且业务允许短暂延迟的场景。

3. 定时重试+幂等校验+状态巡检 #

若暂时无法引入消息队列或改造供应商接口，可采用简单的巡检机制兜底：

• 当调用供应商成功但本地数据库更新失败时，立即记录一条「待修复」交易日志（包含交易ID、供应商返回的预订凭证等信息）。
• 启动定时任务，每隔一段时间扫描「待修复」日志，尝试重新更新本地数据库状态。重试前先调用供应商的「查询预订详情」接口，确认预订确实成功后再执行本地更新。
• 给重试设置次数上限，超过上限后触发告警，通知人工介入处理。

核心要求：

• 本地更新操作必须幂等，例如执行UPDATE transactions SET status='completed' WHERE id=? AND status='initialized'，避免重复更新导致状态混乱。
• 定时任务需做好并发控制，防止同一条日志被多个进程重复处理。

总结 #

优先推荐可靠消息最终一致性，实现成本适中，适配多数互联网业务场景；若供应商可配合提供预留/取消接口，TCC模式的一致性更强；小型项目或临时过渡场景，定时重试+巡检是快速落地的方案。

内容的提问来源于stack exchange，提问作者David Async