6
2016-02-01 23:03:08 +08:00 1
如果纯在 mysql 的场景下操作,不用内存 key-value 系统,我更倾向于用另外一种模型处理这种竞争抢购的逻辑。
“需要先 select ,然后 insert ,最后 update -1 。最后这个-1 操作是不能出现负数的”
我可以分享一下我的思路,以及我的做法。
首先,楼主以及这个文章都提到超售的问题,如果你的系统设计上能出现超售,那说明你的逻辑太差。就这种 select insert update-1 的模型,在抢购的瞬间是怎么操作的呢?我们分析一下:
首先 用户 submit_order, 先去 select 库存,判断有,然后 insert 一个 order 表数据,然后 update 库存减 1
在 MYSQL 并发非常高的瞬间,这三部操作,都可能出现大坑,只要三步中一个操作被锁坑了,整体就坑了。
然后我们再抽象:假设抢购 50000 件商品
抢购前,库存表一条记录 值 50000 ,订单表 0 条记录
抢购后,订单表 50000 条记录,库存表 1 条记录,值 0
在抢购过程中(假设非常火, 5 秒钟抢完)
中间 select 次数远大于 50000 (抢购失败的也得查询库存), update50000 次库存表-1 , insert50000 个订单表 这么多查询吧。这三步是一个顺序逻辑,任何一步出问题整个操作都失败。
我的抢购系统,绝对不会设计的!
我有 50000 件商品,我在抢购开始前一个小时到抢购前 5 分钟, 55 分钟的时间里,写入订单表 50000 条记录。其中 orders 表的 uid 做 unique 约束。 UID 使用-1~-50000 预先填写好
我有 55 分钟时间插入 50000 条记录,不用 5 秒钟, MYSQL 无负载无压力
开始抢购,所有人就开放一个接口,拼命地往数据库里提交一个查询
update ignore `orders` set uid = '你的 UID' where uid<0 and item=3 limit 1
不用等执行结果 完全非阻塞的只接受一个指令 就行了
整个抢购过程,就是一群人发一个查询往里去,等管理端发现 50000 个记录确认都有主了,抢购结束标志设置好,关闭抢购接口,完成抢购。大家可以访问我的订单看抢购结果了。