@crclz #35
15 年前做一种特殊的秒杀（不是卖东西，但是逻辑跟秒杀没区别），那时候还没有 redis，没有 memcache 。
当时的方案是纯 MYSQL，那时还没有云计算弹性扩容
当时就可以很容易的解决秒杀问题，而且严格不能超售。
多开 webserver，mysql 堆 ram 扩大连接数不让他死掉

比如秒杀商品是 100000 件每人限购一件限购一单，直接预先生成 100000 个订单，不在主订单表内，每个秒杀做一个独立的订单表，引擎 memory(heap)

简略的单一项目秒杀独立订单表如下
order_id user_id，……………………其中 user_id 挂唯一索引

所有订单 user_id 预先都设置成 0
秒杀逻辑就是大家拼命往里堆执行
update [table] set user_id = [Your user id] where user_id = 0 limit 1;

秒杀完成后（ 30 秒级），直接预置一个逻辑，把这个特殊表按规则合并到主订单表

缺点就是，30 秒内，[我的订单]看不到秒杀成功的订单……


如果不想依赖手速网速，或者不像搞死最大连接数只有 800 左右的单机 MYSQL，就在前面下概率控制，随机数有一定概率往数据库里写。随机数可以引入时间加权。