【170921】秒杀系统设计狂想曲

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服务机器节点

秒杀大促压测数据