紧张须要办理的问题有两个：
高并发对数据库产生的压力竞争状态下如何办理库存的精确减少（超卖问题）对付第一个问题，已经很随意马虎想到用缓存来处理抢购，避免直接操作数据库，例如利用Redis。重点在于第二个问题，常规写法：
查询出对应商品的库存，看是否大于0，然后实行天生订单等操作，但是在判断库存是否大于0处，如果在高并发下就会有问题，导致库存量涌现负数
流量到了亿级别，常见站点架构如上：
浏览器端，最上层，会实行到一些JS代码站点层，这一层会访问后端数据，拼html页面返回给浏览器做事层，向上游屏蔽底层数据细节数据层，终极的库存是存在这里的，mysql是一个范例三、优化方向1.将要求只管即便拦截在系统上游：传统秒杀系统之以是挂，要求都压倒了后端数据层，数据读写锁冲突严重，并发高相应慢，险些所有要求都超时，流量虽大，下单成功的有效流量甚小【一趟火车实在只有2000张票，200w个人来买，基本没有人能买成功，要求有效率为0】
2.充分利用缓存：这是一个范例的读多写少的运用处景【一趟火车实在只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适宜利用缓存。
四、优化细节4.1.浏览器层要求拦截
点击了“查询”按钮之后，系统那个卡呀，进度条涨的慢呀，作为用户，我会不自觉的再去点击“查询”，连续点，连续点，点点点。。。有用么？平白无端的增加了系统负载（一个用户点5次，80%的要求是这么多出来的），怎么整？
产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交要求JS层面，限定用户在x秒之内只能提交一次要求如此限流，80%流量已拦。
4.2.站点层要求拦截与页面缓存
浏览器层的要求拦截，只能拦住小白用户（不过这是99%的用户哟），高真个程序员根本不吃这一套，写个for循环，直接调用你后真个http要求，怎么整？
同一个uid，限定访问频度，做页面缓存，x秒内到达站点层的要求，均返回同一页面同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的要求，均返回同一页面如此限流，又有99%的流量会被拦截在站点层
4.3.做事层要求拦截与数据缓存
站点层的要求拦截，只能拦住普通程序员，高等黑客，假设他掌握了10w台肉鸡（并且假设买票不须要实名认证），这下uid的限定弗成了吧？怎么整？
大哥，我是做事层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个要求去数据库有什么意义呢？对付写要求，做要求行列步队，每次只透有限的写要求去数据层，如果均成功再放下一批，如果库存不足则行列步队里的写要求全部返回“已售完”对付读要求，还要我说么？cache抗，不管是memcached还是redis，单机抗个每秒10w该当都是没什么问题的如此限流，只有非常少的写要求，和非常少的读缓存mis的要求会透到数据层去，又有99.9%的要求被拦住了
4.4.数据层闲庭信步
到了数据这一层，险些就没有什么要求了，单机也能扛得住，还是那句话，库存是有限的，小米的产能有限，透这么多要求来数据库没故意义。
4.5.mysql批量入库提高INSERT效率
五、Redis利用redis行列步队（list），push和pop操作担保了原子性的实现。纵然有很多用户同时到达，也是依次实行。（mysql事务在高并发下性能低落很厉害）
先将商品库存存入行列步队：
<?php $store=1000; //商品库存$redis=new Redis(); $result=$redis->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中的用户秒杀要求同步到数据库中
六、总结没什么总结了，上文该当描述的非常清楚了，对付秒杀系统，再次重复下两个架构优化思路
只管即便将要求拦截在系统上游读多写少经量多利用缓存redis行列步队缓存 + mysql 批量入库末了读到这的朋友可以转发支持下，同时可以关注我，每周都有定期更新的精选内容分享给大家！
