基于Django的预订会话支付周期处理方案咨询

必须标记待支付会话为已预订 #

不做标记必然会出现超售问题——两个用户同时下单同一会话，最终只能有一个支付成功，另一个会面临支付失败或无法履约的情况，严重影响用户体验，甚至引发纠纷。所以这个标记是必要的。

如何处理用户放弃支付后的状态恢复？ #

推荐结合两种触发方式，确保状态能及时、准确恢复：

1. 支付服务商回调触发
   • 对接Fawry、Paymob的支付回调接口，当收到支付失败、用户主动取消的通知时，立即将会话从临时待预订状态恢复为可预订。
   • 要注意处理回调重复、延迟的问题，比如用支付订单ID作为唯一标识做幂等校验，避免重复修改状态。
2. 定时任务/延迟消息兜底
   • 支付回调可能因服务商故障、网络问题丢失，所以需要兜底机制：
     • 用定时任务（比如Linux Crontab、框架自带的定时任务组件）每隔5分钟扫描临时表，把创建时间超过30分钟且未完成支付的会话恢复为可预订状态。
     • 或者用延迟消息队列（比如Redis过期键通知、RabbitMQ延迟队列），在生成支付码时就创建一个30分钟后触发的延迟任务，到时自动检查支付状态，未支付就恢复会话。后者实时性更强。

关于“恢复后其他用户未再次查询”的顾虑 #

完全不需要纠结这个——后端只需要保证会话状态的正确性即可。用户查询可用会话时，后端返回的是最新状态，只要状态恢复了，用户下次查询就能看到。如果用户之前查过没下单，那是用户自身的选择，后端不需要额外处理（除非你做了会话订阅推送，但这属于额外功能）。

不推荐“保持可预订直到支付完成”的方案 #

这个方案的超售风险是致命的：热门会话很容易出现多个用户同时生成支付码的情况，最后只有一个能成功支付，其他用户的支付相当于无效，体验极差。而且如果支付码不校验会话状态，用户支付成功后发现会话已被他人预订，必然会引发投诉，后续处理成本很高。

你的临时表方案落地建议 #

你的思路是对的，具体可以这么实现：

1. 新增临时表（比如pending_bookings），记录用户ID、会话ID、支付订单ID、创建时间、支付状态。
2. 用户下单生成支付码时，要么将会话从可用会话表移到临时表，要么在可用会话表中增加status字段（比如pending/available/booked），把状态设为pending。
3. 状态切换逻辑：
   • 支付成功：将临时表记录移到已预订表，或者把可用会话表的状态改为booked。
   • 支付失败/超时：删除临时表对应记录，将会话移回可用表，或者把状态改回available。

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