具体忘记在哪看的，貌似是51CTO的订阅号
一. 为什么难
系统秒杀难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据
二. 常见架构
浏览器->站点->服务->数据：这是流量到达亿级别常见的架构
1.浏览器端，最上层，会执行一些js代码
2.站点层，这一层会访问后端数据，拼html页面返回给浏览器
3.服务层，向上游屏蔽底层数据细节
4.数据层，最终的库存是存在这里，mysql是一个典型
三. 优化方向
1.将请求尽量拦截在系统上游：传统秒杀系统之所以会挂，请求都压到了后端数据层数据读写锁冲突严重，并发高，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小（一趟火车其实只有2000张票，200w人来买，基本没有人能买成功，请求效率为0）
2.充分利用缓存：这是一个典型的读多写少的应用场景，一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存
四. 优化细节
1.浏览器层请求拦截
问题：点击了“查询按钮后”，系统反应会卡，会比较慢，作为用户会不自觉的再去多次点“查询”。没用的同时平白无故增加了系统负载。
解决：<1>.产品层面，用户点击查询或者购票后，按钮置灰，禁止用户重复提交
<2>.js层面，限制用户在x秒之内只能提交一次请求
如此限流，80％流量已拦截
2.站点层请求拦截和页面缓存
问题：浏览器层的请求拦截，只能拦住小白用户（不过这是99%的用户呦），高端程序猿根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
解决：<1>.同一个uid，限制访问频率，做页面缓存，x秒到达站点层的请求均返回同一页面
<2>.同一个item查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面。
如此限流，又有99%的流量会被拦截在站点层
3.服务层请求拦截与数据缓存
问题：站点层的请求拦截，只能拦住普通程序猿，对于高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧，怎么办？
解决：<1>.大哥，我是服务层，我清楚的知道小米只有一万部手机，我清楚的知道一列火车只有2000张票，我通过10万个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只通过有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”。
<2>.对于读请求，还用说吗，cache来扛，不管是memcached还是redis，单机扛个每秒10w应该都是没什么问题，如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。
4.数据层闲庭信步
到了数据这一层，几乎就没什么请求了，单机也能扛得住，还是那句话，库存是有限的，小米的产能是有限的，透过过多请求来数据库没有意义。
五. 总结
对于秒杀系统：
1.尽量将请求拦截在系统上游
2.读多写少的多使用缓存
网友评论