阅读 2380

秒杀系统设计狂想曲

原文链接: www.jianshu.com

hi,rudy,我们这一次要做个活动,大家一起来抢100张1000元现金券。你看看怎么做?现在预约人数大概在2w人左右。我擦,秒杀啊,这个得想想如何利用自己现有资源来完成瞬间的高并发处理。

他山之石

秒杀的特点

  • 对现有网站业务造成冲击
  • 瞬间的高并发,但秒杀商品数量有限。真正有效请求有限。而且一般是热点数据比较多。
  • 网络及服务器带宽增长压力。
  • 业务逻辑的简化

原则

  • 不能超卖,高并发下的数据的强一致性
  • 公平性
  • 可扩展性:可以通过增加服务数量,来抗住更大的并发
  • 分流:基于时间分片削峰

解决方式

  • 公平性:

    • 防刷机制-限制n秒内,用户访问次数、
    • 验证码
    • 倒计时前后端时间同步
    • 僵尸账号防刷-在业务侧做实名制
  • 隔离:

    • 业务隔离:秒杀系统,属于短时间高并发处理,防止影响其他正常业务,应该需要独立部署
    • 动静隔离:秒杀页面尽可能减少对后台依赖,绝大部分走CDN,只有少量动态数据请求服务器
  • 网络及服务器带宽增长压力:

    • 尽可能越在靠近用户侧拦截越多无效请求越好。
    • 减少冗余数据的返回
  • 保证秒杀接口快:

    • 秒杀接口足够简化
    • 复杂逻辑异步处理
    • 尽可能越在靠近用户侧拦截越多无效请求越好。
    • 读走缓存
  • 数据一致性:

    • 将大量无效请求拦截在数据层之前,有效请求(少量)通过redis/db等中间数据层保证数据一致性
  • 可扩展性:

    • 多级缓存:各个层级,尽可能多的做缓存,以拦截无效请求。

方案一

秒杀系统设计-方案一.png
秒杀系统设计-方案一.png
  • 优点与说明:

    • 实现相对简单,能做一部分秒杀活动。
    • 前端静态资源走CDN
    • 前端做秒杀前后拦截,秒杀中,每个用户只放一次请求到后端。可以拦截掉小白用户的99%的无效点击。
    • 利用redis的(setnx、incrby/decrby等原子操作)、mysql的(for update 写锁)实现秒杀库存控制
  • 缺点:

    • 比较倚重redis
    • 过滤用户秒杀条件成为瓶颈
    • 业务耦合还是比较严重

方案二

秒杀系统设计-方案二.png
秒杀系统设计-方案二.png
  • 优点与说明:

    • 增加单机本地缓存,可以支持机器平行扩容,抗住更多请求
    • 增加mq,做异步处理,解耦复杂的业务逻辑
  • 缺点:

    • 没有机器人爬取。多个商品秒杀咋办?
    • 有没有什么降级处理?
    • 数据层还是单点

方案三

.....

叮叮叮,叮叮叮,rudy起来了,午休结束了,起来搬砖了.....

文章分类
后端