hi，rudy，我们这一次要做个活动，大家一起来抢100张1000元现金券。你看看怎么做？现在预约人数大概在2w人左右。我擦，秒杀啊，这个得想想如何利用自己现有资源来完成瞬间的高并发处理。
他山之石
- 徐汉彬：Web系统大规模并发——电商秒杀与抢购：http://www.csdn.net/article/2014-11-28/2822858
- 秒杀系统架构分析与实战：http://www.cnblogs.com/andy-zhou/p/5364136.html
- 小米网抢购系统开发实践：http://www.csdn.net/article/2014-11-07/2822545
- 如何设计一个秒杀系统：http://www.jb51.net/article/108564.htm
秒杀的特点
- 对现有网站业务造成冲击
- 瞬间的高并发，但秒杀商品数量有限。真正有效请求有限。而且一般是热点数据比较多。
- 网络及服务器带宽增长压力。
- 业务逻辑的简化
原则
- 快
- 不能超卖，高并发下的数据的强一致性
- 公平性
- 可扩展性：可以通过增加服务数量，来抗住更大的并发
- 分流：基于时间分片削峰
解决方式
-
公平性：
- 防刷机制-限制n秒内，用户访问次数、
- 验证码
- 倒计时前后端时间同步
- 僵尸账号防刷-在业务侧做实名制
-
隔离：
- 业务隔离：秒杀系统，属于短时间高并发处理，防止影响其他正常业务，应该需要独立部署
- 动静隔离：秒杀页面尽可能减少对后台依赖，绝大部分走CDN，只有少量动态数据请求服务器
-
网络及服务器带宽增长压力：
- 尽可能越在靠近用户侧拦截越多无效请求越好。
- 减少冗余数据的返回
-
保证秒杀接口快：
- 秒杀接口足够简化
- 复杂逻辑异步处理
- 尽可能越在靠近用户侧拦截越多无效请求越好。
- 读走缓存
-
数据一致性：
- 将大量无效请求拦截在数据层之前，有效请求（少量）通过redis/db等中间数据层保证数据一致性
-
可扩展性：
- 多级缓存：各个层级，尽可能多的做缓存，以拦截无效请求。
方案一
秒杀系统设计-方案一.png
-
优点与说明：
- 实现相对简单，能做一部分秒杀活动。
- 前端静态资源走CDN
- 前端做秒杀前后拦截，秒杀中，每个用户只放一次请求到后端。可以拦截掉小白用户的99%的无效点击。
- 利用redis的（setnx、incrby/decrby等原子操作）、mysql的（for update 写锁）实现秒杀库存控制
-
缺点：
- 比较倚重redis
- 过滤用户秒杀条件成为瓶颈
- 业务耦合还是比较严重
方案二
秒杀系统设计-方案二.png
-
优点与说明：
- 增加单机本地缓存，可以支持机器平行扩容，抗住更多请求
- 增加mq，做异步处理，解耦复杂的业务逻辑
-
缺点：
- 没有机器人爬取。多个商品秒杀咋办？
- 有没有什么降级处理？
- 数据层还是单点
方案三
.....
叮叮叮，叮叮叮，rudy起来了，午休结束了，起来搬砖了.....
20180620补充，方案一的压测数据
2台php服务机器节点
秒杀大促压测数据
