WebAPI 防止竞争条件答案

【问题标题】：WebAPI Preventing Race ConditionsWebAPI 防止竞争条件
【发布时间】：2015-05-21 20:01:34
【问题描述】：

我有一个 WebAPI POST 控制器方法，它基本上只是将带有数量值的记录插入到表中。我需要根据可用数量检查该数量。问题是我可以同时发生多个提交，并希望消除任何可能的竞争条件。

有很多方法可以做到这一点，但我正在尝试确定最佳方法。我曾想过使用队列，但随后客户端设备将需要进行检查以查看状态。我想过使用单例模式，但是客户端将不得不等待发布。

有人指点一下吗？

【问题讨论】：

您的控制器能否更改为处理 2 个值，第二个值是时间戳..？
它可以，完全控制功能。只需要保持 RESTful。
如果这一切都发生在一台服务器上，您所要做的就是创建一个静态锁对象并在更新和读取期间使用相同的锁对象。这将防止对 DB 造成混淆。否则，即使您阅读了该记录，您也可以锁定它。但这与 Web Api 无关。这是并发问题。
@T.S.你能举个例子吗？
@T.S.：你不能可靠地将你的并发解决方案建立在应用服务器端的锁上，因为这会阻止你的应用服务器在未来集群化。 “静态锁”不会神奇地跨越两个或更多服务器。或者我误读了你写的内容。

【解决方案1】：

您的问题与 WebAPI 无关，而是与您的数据和数据管理层有关。 WebAPI 不应该关心数据，它的作用是接受请求并发送回响应。响应取决于输入数据、验证、业务逻辑等。

您的问题是经典的并发控制问题。答案有很多，正确的答案取决于您的系统和架构。

我假设您的数据库事务涉及这些步骤？： 1) 带有数量的新记录插入 2）数量更新（新总数=总数-数量）它们必须同时发生还是根本不发生？

一种方法是Optimistic Concurrency。让数据库（或您的 ORM（即实体框架））告诉您数量计数器是否过时，如果它过时，请再次查询并验证可用数量是否仍然有效。

您需要在谷歌上搜索如何为您的数据库实现乐观并发。简而言之，就是表上的一个时间戳，不能盲目修改。当更新发送到数据库时，它包含在更新之前已经检查过的时间戳值，如果仍然匹配，则事务通过，如果值不同，则中止事务。

【讨论】：

使用乐观并发的问题在于数据库的架构。可用数量存储在一个记录中，而另一组记录的总和表示已提取。因此，并发插入第二张表可能会导致数量过多。这就是让我找到排队解决方案的原因。这样客户端就可以等待，队列永远不会很大，所以我希望将其限制在 API 或 BLL 层中。
如果所有操作都通过您的 API 完成，并且没有其他方法可以影响可用数量和“已获取记录”的总和（即 dba 或其他系统插入记录），那么您可以计算取一次总和（例如在系统启动时）并将其保存在某种计数器中？在交易期间使用它，并在每次操作时更新它。这将加速您的系统，并消除每次计算总和的需要。附言我建议您将此问题移至programmers.stackexchange。因为它更多的是设计问题。会有更多的观点和想法。