订单系统中并发问题与锁机制的探讨

问题的根源

假设在订单管理系统开发计划中（以火车票订购系统为例），用户A和用户B必须预订从成都到北京的火车票。 A和B都在不同的售票窗口调查某个隔间卧铺。下铺有空间。当用户B果断订购下铺时，用户A对订购商店或底层商店犹豫不决。当用户A决定订购下铺时，系统会提示已预留下铺，请重新选择下铺。在这个系统场景中，让我们探讨火车票系统如何处理并发事件以及如何使用锁机制来避免重复预订。

为了避免重复预订，大多数人会在进行预订操作之前考虑去数据库检查商店是否已被预订，假设“商店”数据库表添加了标签字段FLAG（空闲：0;预订： 1），if如果下铺的FLAG字段值为1，则保留不成功。如果为0，则保留成功并且FLAG设置为1.如果这种解决方案位于具有少量流量的系统中，则这种解决方案可能是可行的。但是，当有大量的业务，特别是火车票的数量时，就会出现问题。问题是当用户A和用户B同时订阅同一商店时，虽然它是“同时”的，但必须有一个数据库操作的序列。如果A正在查询商店的FLAG，则值为0，准备就绪。订阅设置为值1，而B已经成功订阅并将FLAG设置为1.因为A没有对FLAG=1的即时查询，所以保留成功，并且FLAG设置为1./p>

这导致重复预订。在票务高峰期，使用这样的方案，重复预订是不可避免的。

我们想过使用数据库的悲观锁来解决这个问题。想象一下，如果用户A查询他想要预订的票证，则用户B根本找不到它。只有A可以看到它。是否可能没有重复预订？因为没有人在抢劫他。

这可以这样实现：

选择* from table where ...... for update skip locked，该语句是查询用户指定的票证信息，并锁定（for update），如果有记录被锁定，则自动跳转到下一条记录（跳过锁定），所以无论谁先查询，都可以慢慢考虑是上升还是下降。但火车票系统是这样做的吗？显然不是，因为用户体验太差，门票实际上很多，但不明显的是它不能买，这显然是不合理的。

我们还考虑从订单管理系统程序级解决并发问题。最简单的方法是使用同步来处理它，但我们需要知道必须以群集模式部署大型系统。同步只能解决单节点环境的并发问题。要解决此问题，您仍必须依赖全局锁定机制。

现在我们回到数据库中，我们考虑一下。如果我们在查询时使用乐观锁定，那么当我们在预订前使用悲观锁定时会发生什么？例如，当我们查询：

从表中选择* ......

用户A和用户B都有相同的票务信息（中间商店和较低的商店），而用户A或用户B在预订时会产生悲观锁定：

选择*从表格中......进行更新（仅用于预订票证做悲观锁定）

此时，后者无法在预订时获取记录的锁定，自然也无法进行预约，从而避免了重复预约的问题。

随商信息技术（上海）有限公司 b2b2c多用户商城系统是基于PHP技术的企业级电子商务平台系统，系统支持平台自营、招商加盟和多商家入驻、集成微信商城、移动端APP商城、微信小程序于一体。公司主营业务包含商城系统定制开发、新零售系统解决方案、电商平台系统定制开发、商城网站建设服务等等，随商为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建、部署和管理其电子商务平台，拓展企业销售渠道，致力于推动PHP技术和电子商务行业的发展而不断努力。