新闻 > 市场·视野

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

问题由来

假设在订单管理系统开发方案中(以火车票订单系统为例),用户A,用户B都要预定从成都到北京的火车票,A、B在不同的售票窗口均同时查询到了某车厢卧铺中、下铺位有空位。用户A正在犹豫订中铺还是下铺,这时用户B果断订购了下铺。当用户A决定订下铺时,系统提示下铺已经被预订,请重新选择铺位。在这个系统场景中,我们来探讨一下,火车票系统是怎样处理并发事件以及怎么利用锁机制来避免重复订票的。

方案1:

为了避免重复订票,大部分人会想到在做订票操作前,去数据库查询该铺位是否已经被预订,假设“铺位”数据库表增加标记字段FLAG(空闲:0;已预订:1),如果查询到铺位的FLAG字段值为1,那么预订就不成功,如果为0就成功预订,并把FLAG置为1。这种方案如果在业务量很少的系统中,或许可行。但业务量较大时,特别是火车票这样的业务量,就会出现问题。问题在,当用户A、用户B同时对同一铺位预订时,虽说是“同时”,但对于数据库操作来说一定是有先后顺序的,假设A在查询该铺位的FLAG时,值为0,准备预订并将值设为1,而与此同时B已经预订成功,并已将FLAG设为1。而A因为没有即时查询到FLAG=1,因此也预订成功,又将FLAG设为1。

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

这样就造成了重复订票,在购票高峰期,使用这样的方案,重复订票不可避免。

方案2:

我们想到了利用数据库的悲观锁来解决这个问题,设想假如用户A查询到想预订的票,用户B根本都查询不到,只有A一个人能看到,那是不是没有重复订票的可能了,因为压根没人跟他抢。

可以这样实现这个方案:

select * from table where …… for update skip locked,该语句是查询用户指定条件的票信息,并加锁(for update),如果有记录已经被锁则自动跳到下一条记录(skip locked),这样谁先查询谁就可以慢慢的考虑要上铺还是下铺。但火车票系统是这样做的吗?显然不是,因为这样用户体验太不好,票实际还很多,但确看不到买不到,这显然不合理。

方案3:

我们又想到了订单管理系统程序层面来解决并发问题,最简便的方式是利用synchronized来处理,但我们要知道一个大型系统必然是集群方式部署的,synchronized只能解决单节点环境的并发问题,要解决此问题还是必须依赖全局性的锁机制。

方案4:

既然又回到了在数据库上加锁,我们又想一下如果我们在查询时,使用乐观锁,但在预订之前使用悲观锁会怎样呢?例如我们查询时:

select * from table where ……

用户A、用户B都查询到了相同的票信息(中铺和下铺),用户A或用户B在预订时做一次悲观锁:

select * from table where …… for update(只对预订的票做悲观锁)

此时后者在预订时,无法获取该记录的锁,自然就无法预订,避免了重复预订的问题。

文章来源:博客园

<赤朝云(www.chichaojituan.com)是国内知名企业级O2O电商平台提供商,为企业级商家提供系统开发(多种模式电商平台搭建:B2B/B2B2C/B2C/O2O/跨境/新零售等)、O2O系统搭建跨境电商解决方案服务>

分享到:

上一篇:多用户商城系统方案:技术架构亮点分析

下一篇:电商订单系统

相关阅读推荐

文章推荐阅读

  • 华上酒业O2O半年超30万分销、破亿销售额,绝招何在?

    华上酒业O2O半年超30万分销、破亿销售额,绝招何在? 到底什么原因,能让华上集团在如今酒业整体低迷、传统模式销售困难的大环境下,业绩如此蒸蒸日上?

  • 互联网+订餐=脏乱差?赤朝携手宜家送菜打破僵局

    在互联网飞速发展的今天,赤朝集团为宜家送菜专业打造O2O网络商城,结合生态平衡立体种养,培育优质的农业种养基地,打造一条完整的360°闭合式环形O2O产业链;创建是食品追溯智能系统,从源头把控食品安全。

  • 全城瞩目:赤朝携手粽子在线企业O2O定制系统震撼登场

    赤朝集团携手旗下分公司粽子在线的企业O2O定制商城系统,日前正式启动。该系统包含分销功能、通话功能、独立APP、会员系统以及微商城系统等五大功能的O2O全渠道运营系统,可根据企业本身不同的需求多元化定制,为各企业网上开店的运营、免除高昂广告费等问题提供解决方案。

文章排行