@jarlyyn
反正我发现他们出来的开发，天天把这个挂嘴上……

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

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

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

别纠结 SKU 什么的。
很讨厌跟阿里系出身的程序员、受阿里系代码逻辑影响谈商城系统设计。
天天就 SKU SKU 的……

只要有任何参数不同的，就是两种商品。
然后，提现所谓 SKU 的，只是显示层聚合，就是在 itemshow 的页面里面，根据配置去把本质是定义成不同的商品的东西聚合显示而已。

这种结构清晰，性能损失小，而且容易充分利用缓存系统。

国内环境，用原生绝逼死得快……
没有个系统底层实现的唤醒处理，权限处理机制，等着坑吧……

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

@php230
pconnect 是 mysql 最大的一个骗局……
为啥 mysqli 都没有 pconnect 了……

建议实测 mysql_pconnect

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

按 PSR 规范貌似要求下一行

但是我烦死新建一行了……都是同行

V2EX 喷子太多了

人家并没说 LINUX 好， WINDOWS 不好吧，人家只是想从事 linux 相关工作，这都不行？

我一直觉得网站下面写那个 copyright 的东西 就是装 X 用的

PHPer ，个人用后一种，最主要原因是省一个空行，一屏幕能多显示出很多代码。

但是 PSR 规范要求前一种，十分搞不懂连特么括号怎么写都规定……

现在啥情况不知道，反正一年前我有这需求时候，下载个 windows 傻瓜包就行了……

美国加州，美国加州最大的同性交友俱乐部 GitHub 倒闭啦！王八蛋老板烧服务器，欠下三点五个亿，带着他的小姨子麦克布克跑啦！我们没有办法，拿着服务器上的私人版本库代码卖钱。原价两千万，三千万的大公司私有代码，现在只要五百块，五百块啊！

我觉得对于楼主来说还是回归 apache 能省事一些……