rest - 在某些情况下防止 RESTful api 中的竞争条件

我目前正在开发一个在线课程系统，学生可以选择任何课程并注册它。该课程将以一对一的原则进行，因此学生将选择课程的特定日期，并在该日期与讲师进行在线视频会议。每个课程只有一名教师和一名学生。典型的用例流程是：

在这种情况下可能会出现竞争条件（假设只有 2 个用户和 1 个讲师）：

我不想在付款前检查日期可用性，所以我认为这会给用户带来不好的体验，因此用户必须再次转到上一步并选择另一个日期。即使这也可能无限发生:)

任何想法都会受到欢迎。此外，我可以更改当前的注册流程以保护安全。

标签： restarchitecturerace-conditionsystem-design

您要查看的参考文献是 Pat Helland 2007：Memories, Guesses and Apologies

您有一个分布式系统，远程客户端正在查看可能已过时的数据的本地副本。因此，您的协议需要认识到您将收到有关基于陈旧数据的决策的消息，并对当前无法获得所需决策结果的突发事件进行明确处理。

REST 部分“只是”为您的协议提供正确的可供性。

对您的协议可能有所帮助的一种可能更改是引入临时保留的想法；爱丽丝对时隙有一个临时保留，因此当鲍勃要求时隙不可用时，如果爱丽丝拒绝行使该选项，它可能会在稍后变得可用。

（这并没有消除竞争条件，当然，它只是移动它）。

一个常见的协议解决方案是超额预订 - 您在时间段上接受两个声明，然后稍后清理混乱。

商业航空公司一直在做这种事情。他们希望最大限度地提高每次飞行的利润，这意味着售出的机票比飞机上的座位还多。他们可以做到这一点，因为有足够多的旅行者后来改变了他们的计划，从而产生了有效的盈余。

但有时，太多的付费客户出现在同一个航班上，然后应急计划就出来了——候补旅客被推迟，出票客户因改变计划而获得补偿，等等。

无论如何，您可能都需要应急协议（如果讲师不得不取消约会，例如因为生病，会发生什么情况）；预订期间的比赛条件只是添加到运行手册中的另一种应急协议。

在确定了应急协议应该是什么之后，您还有第二个问题需要探索：该协议的哪些部分应该是自动化的。如果冲突很少见，将问题上报给人类解决可能是有意义的，而不是在代码中这样做。有时正确的答案是让机器不碍事。