如何避免数据库锁

Question

我正在做一场比赛的后端。玩家首先购买他们的门票，这些票存储在数据库中，然后他们就可以玩了，并且可以赢得一定的奖品。每位玩家最多可以买60张票。

出现了一个新的要求，为每场比赛的门票总数设定了一个上限-- 10 000张。实现将在购买端点中添加一个测试，以检查当时购买的门票总数+当前购买所需的门票数量小于或等于该游戏的最大票数，以便接受购买。

问题是，使用“票证”表计算当前购票数量时，返回的值可能是过时的，因为在此期间，其他玩家可能已经购买了票。

一个可能的解决方案是在购买期间锁定票证表，但这可能会对性能和用户体验产生负面影响。如果你有不同的想法，请告诉我。

Answer 1

如果您的采购是一个严格的限制，那么您必须避免同时进行多次采购。在DB中使用适当的表锁可能是完成这种序列化的最佳方法。还有其他的选择(例如在前端的某个地方执行序列化)，但它们的实现可能比较混乱，更容易出现错误，而且性能更差。

事实上，如果不对DB进行适当的锁定，可能很难使您的游戏表现出一致的行为。另一方面，您可能不需要显式锁定。如果您用适当的事务隔离级别配置数据库，那么它应该为您执行所有必要的锁定。

由于这里没有明显的胜利，所以我建议搁置性能问题，直到您能够真正测试性能为止。如果结果证明不够好，那么您可以从实际测量中确定系统的哪些部分可以从调优中获益最大。