摘要：一为什么难秒杀系统难做的原因库存只有一份，所有人会在集中的时间读和写这些数据。又例如抢票，亦与秒杀类似，瞬时流量更甚。
一、为什么难
秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，亦与秒杀类似，瞬时流量更甚。
主要需要解决的问题有两个：
高并发对数据库产生的压力
竞争状态下如何解决库存的正确减少（超卖问题）
对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用Redis。重点在于第二个问题，常规写法：
查询出对应商品的库存，看是否大于0，然后执行生成订单等操作，但是在判断库存是否大于0处，如果在高并发下就会有问题，导致库存量出现负数
流量到了亿级别，常见站点架构如上：
浏览器端，最上层，会执行到一些JS代码
站点层，这一层会访问后端数据，拼html页面返回给浏览器
服务层，向上游屏蔽底层数据细节
数据层，最终的库存是存在这里的，mysql是一个典型
三、优化方向1）将请求尽量拦截在系统上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】
2）充分利用缓存：这是一个典型的读多写少的应用场景【一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适合使用缓存。
4.1）浏览器层请求拦截
点击了“查询”按钮之后，系统那个卡呀，进度条涨的慢呀，作为用户，我会不自觉的再去点击“查询”，继续点，继续点，点点点。。。有用么？平白无故的增加了系统负载（一个用户点5次，80%的请求是这么多出来的），怎么整？
a 产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求
b JS层面，限制用户在x秒之内只能提交一次请求
如此限流，80%流量已拦。
4.2）站点层请求拦截与页面缓存
浏览器层的请求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
a 同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
b 同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面
如此限流，又有99%的流量会被拦截在站点层
4.3）服务层请求拦截与数据缓存
站点层的请求拦截，只能拦住普通程序员，高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎么整？
a 大哥，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”
b 对于读请求，还要我说么？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了
4.4）数据层闲庭信步
到了数据这一层，几乎就没有什么请求了，单机也能扛得住，还是那句话，库存是有限的，小米的产能有限，透这么多请求来数据库没有意义。
4.5）mysql批量入库提高INSERT效率
五、Redis使用redis队列（list），push和pop操作保证了原子性的实现。即使有很多用户同时到达，也是依次执行。（mysql事务在高并发下性能下降很厉害）
先将商品库存存入队列：
connect("127.0.0.1",6379);
$res=$redis->llen("goods_store");
for($i=0; $i<$store; $i++){
$redis->lpush("goods_store",1);
}
echo $redis->llen("goods_store");
?>
客户执行下单操作：
$redis=new Redis();
$result=$redis->connect("127.0.0.1",6379);
$count = $redis->lpop("goods_store");
if(!$count){
echo "抢购失败！";
return;
}
缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中
六、总结没什么总结了，上文应该描述的非常清楚了，对于秒杀系统，再次重复下两个架构优化思路：
1）尽量将请求拦截在系统上游
2）读多写少经量多使用缓存
3) redis队列缓存 + mysql 批量入库
参考文档1：秒杀系统架构优化思路
参考文档2：【高并发简单解决方案】redis队列缓存 + mysql 批量入库 + php离线整合
参考文档3：PHP+Mysql高并发解决
参考文档4：php结合redis实现高并发下的抢购、秒杀功能
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/61859.html
摘要：作为面试官，我是如何甄别应聘者的包装程度语言和等其他语言的对比分析和主从复制的原理详解和持久化的原理是什么面试中经常被问到的持久化与恢复实现故障恢复自动化详解哨兵技术查漏补缺最易错过的技术要点大扫盲意外宕机不难解决，但你真的懂数据恢复吗每秒 作为面试官，我是如何甄别应聘者的包装程度Go语言和Java、python等其他语言的对比分析 Redis和MySQL Redis：主从复制的原理详...
摘要：作为面试官，我是如何甄别应聘者的包装程度语言和等其他语言的对比分析和主从复制的原理详解和持久化的原理是什么面试中经常被问到的持久化与恢复实现故障恢复自动化详解哨兵技术查漏补缺最易错过的技术要点大扫盲意外宕机不难解决，但你真的懂数据恢复吗每秒 作为面试官，我是如何甄别应聘者的包装程度Go语言和Java、python等其他语言的对比分析 Redis和MySQL Redis：主从复制的原理详...
阅读 3589·2023-04-26 02:32
阅读 3766·2021-11-23 10:05
阅读 2274·2021-10-08 10:04
阅读 2676·2021-09-22 16:06
阅读 3594·2021-09-22 15:27
阅读 733·2019-08-30 15:54
阅读 1643·2019-08-30 13:50
阅读 2589·2019-08-29 13:56
