mysql update 库存问题

一个提示 ... Redis 的所有命令都是原子性的 ... 其中包括 INCRBY ...

今天净碰到商城相关的问题是为什么 ...

你给的文章也说明白了， mysql 就是一个数据库， 高并发的问题解决不了，也不应该让 mysql 来解决，只能把逻辑提出来处理。

@yangqi 现在的问题是同事问我说他只要把字段设为 unsigned int 就不会出现库存为负情况，我测试了下确实如此，没有出现超卖

@sheldondai 你这个只能保证库存不为负。但是如果库存为 1 的时候，多个人同时下单成功的情况你怎么处理?

@yangqi 测试结果是只有一个可以 update 成功

如果纯在 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 个记录确认都有主了，抢购结束标志设置好，关闭抢购接口，完成抢购。大家可以访问我的订单看抢购结果了。

@realpg 兄弟这个做法和我们之前的做法类似，确实可以保证不会超发。不过今天跑到 V2EX 上主要是想解决我同学问我的问题，在 mysql 性能够用的情况下，对一个无符号的 int 进行 updte-1 也可以保证不超发

begin
select .... for update;
update .... where ....;
commit;

@sheldondai 你库存和订单存在一个表里？你得先说清楚你的操作流程，不然不好判断

@sheldondai
不只是超售的问题，超售属于算法 0 分不及格。
性能差，抗压能力差两个量级。

不能小于 0 ，所以改成无符号整数，然后库存变成了 4294967295 ……

@yangqi 是这样的，我们不是专门做电商公司。是现在有个小活动让用户抽奖，有个同事的方法是这样，有个表保存库存量
```
1. 有用户请求，检查库存是否大于 0
2.大于 0 的话，则 update-1 ，如果 update 成功就算抽奖成功
```
当然中间计算概率的在这省略了。


@realpg 感谢，我们现在并发更高的项目里用的是另外两种方法，一种和你们的类似，另一种是使用了 redis 。效果也都不错。今天主要是想问下 update-1 的问题

@skydiver 我们测试不会出现这种情况， mysql5.6

@sheldondai
提前把每个货物分开
使用事务，有请求的时候，先把库存表里锁住一个货物，然后处理完改状态，

@sheldondai 这样自然是可行的，不过有个前提就是 mysql 的 SQL_MODE 不能为'NO_UNSIGNED_SUBTRACTION', 否则 update 不会出错，只会返回 warning.

你这个和秒杀类的不一样，要简单多了

@yangqi 我们用的阿里云的 RDS ，刚查了下是空。但执行 sql 确实报错了
BIGINT UNSIGNED value is out of range in '(`yao_admin`.`article`.`status` - 1)'。

这个设置之前不知道，学习了。那网上很多文章里说的库存减为负的是怎么出现的呢

@sheldondai 那些自然是字段没有设为 unsigned ，因为这样没用，而且也不是最优方案。因为 update 失败后返回错误，你还要检查错误是否是 out of range 。如果只看是否成功，出了其他问题没有 update 成功都算作库存为 0 的话问题就来了。

@sheldondai
现在都是依托内存 kv 引擎做这种东西了。性能极强，抗压能力提升三个量级以上。

我很早就搞过这种东西的算法，各种避免 select 再 update 的模型，最开始的理由极其朴素
你有没有发现我提到的这种算法可以不依赖支持事务的引擎？

最开始就是在高并发的前提下， MyISAM 引擎上跑类似这种逻辑，才提出的这种方案……

@realpg 你这用法感觉跟游戏公司一个用户一个表有异曲同工之妙啊。

@realpg ???求解决淘宝超售问题。

redis INCRBY + mysql update - 1 where > 0

@sheldondai 重点不是有没有这种情况，重点是解决问题的思路太奇葩……

秒杀系统的高峰 QPS 是多少，期望解决问题的成本有多高（比如开发量多大能接受）。

如果没有这两个限制条件，讨论下去没有最优解，因为很多 NB 的技术太复杂，实现成本比较高。

先经过 redis 原子操作下

这个问题与我正要解决的问题相同，正准备试试 @realpg 的方法。