秒杀系统设计思路与实战(含源码实现)

一、限流与降级

客户端限流

  1. 按钮置灰
  2. js控制每秒只能发送一个请求

站点层限流

1. Nginx限流

Nginx官方版本限制IP的连接和并发分别有两个模块:

  • limit_req_zone: 用来限制单位时间内的请求数,即速率限制,采用的漏桶算法。
  • limit_req_conn: 用来限制同一时间连接数,即并发限制。
2. 站点层限流

客户端限流一般可以限制住普通用户,对于高端用户,则可能使用脚本刷,或者实际抢购的用户量确实大,故需要在站点层进行限流,如单个部署实例的每秒最大请求数,每个用户每秒的最大请求或者通过Redis记录和限制单个用户只能请求一次。

写流量
  • 根据uuid限制每个用户每秒只能一个请求,如使用guava的RateLimiter在进程限流,故如果多个节点,则每个用户可请求数量实际是节点个数倍;或者通过Nginx将相同的uuid转发到相同的机器上面。
读流量:
  • 页面缓存和页面数据缓存。页面缓存可以是进程缓存,页面数据缓存一般是分布式缓存,保持各节点的数据一致性,如库存数量可以放到分布式缓存中。

降级

  • 如果流量太大,导致站点层限流后还是出现问题挂了或者站点层没问题,队列出问题了,则需要采取降级策略。
  • 对于站点层出问题,则可以在客户端直接提示“服务器繁忙,稍后再试”。
  • 对于队列挂了或者Redis挂了无法读取到库存信息,则可以在站点层降级处理,直接返回和提示“抢购人数太多,请稍后尝试”。

二、队列削峰

通过第一步限流后,将合法流量放到一个队列中,实现流量削峰,达到流量可控和异步处理。

入队条件

  • 秒杀的数量有限,所以不需要将第一步限流中成功通过的所有请求都放到队列中,而是可以先将库存数量放到分布式缓存中,如Redis,然后先检查库存是否还有,即数量大于0:
    1. 有则扣减库存,则将该请求放到队列中,注意这里存在读数量get,递减数量两个过程,故分布式里面存在并发问题,即两个机器同时读都是100,都递减1,写回99,则其实是减了2,所以这里的数字不是精确的,即放到队列的数据是大于100的,不过具体下单扣减是在后台服务消费队列时使用,故该并发问题对秒杀来说问题不大。如果需要保证一致,则可以使用Redis实现一个分布式锁,即setnx的使用,不过秒杀系统不需要,否则并发量会急剧下降。
    2. 否则库存不足,直接返回抢购完毕,或者可以优化一下说“抢购完毕,如果有小伙伴放弃,可以继续抢购”来避免队列消息处理失败导致还有没卖完。

请求响应

  • 入队成功或者失败都可以将该请求直接返回了,不过页面可以显示等待中或者提示抢购结果稍后通知,如现在很多抢票都是这样的。

三、服务层异步处理

  • 服务层消费队列的数据,由于此时速度是可控的,故可以起一个后台服务节点即可,这个后台服务可以使用一个线程来执行这个操作就可以了,这样就不存在竞争问题。如果需要多个后台服务或者多个线程,则可以依赖数据库的自身的锁即可,如乐观锁,来解决并发问题。所以由该后台服务消费队列的数据,进行下单操作,递减数据库库存。
  • 如果消费队列的某个数据失败,可以采用fail-fast的原则,直接提示失败,不需要进行重试之类的复杂操作。

四、抢购结果通知

由于使用了队列来异步处理,即入队后或者库存不足无法入队,该次抢购请求是直接返回了的,故对于抢购结果是需要进行额外通知的。

1. 客户端轮询

可以通过客户端定时请求服务端,如每秒发送一个请求,如果成功,则提示抢购成功;失败,则返回失败。例如,客户端可以在没有轮询到处理结果时提示“抢购中,请耐心等待”,如果轮询到结果则提示成功或失败。

2. 消息推送

另外一种方式可以是直接通过消息推送的方式来通知用户抢购结果。

五、完整架构示意图

秒杀系统设计思路与实战(含源码实现)_第1张图片
其中站点层也就是web网关层,提供web API接口,如上图的站点1、2、3是一个 Web 网关集群的多个部署节点,通过 Nginx 来进行负载均衡实现请求的分发。

六、项目实战

以上介绍了秒杀系统设计的基本思路,具体的实现代码可以参加本人的Github:电商网站与秒杀系统:eshop

你可能感兴趣的:(分布式架构)