秒杀系统设计思路

秒杀系统设计思路

2019年05月08日 22:38:15 backend_coder 阅读数:1913更多

个人分类: 分布式架构

版权声明:非商业目的可自由转载,转载请标明出处 https://blog.csdn.net/u010013573/article/details/89979149

一、限流与降级

客户端限流

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

站点层限流

1. Nginx限流

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

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

2. 站点层限流

客户端限流一般可以限制住普通用户,对于高端用户,则可能使用脚本刷,或者实际抢购的用户量确实大,故需要在站点层进行限流。

写流量

  • 根据uuid限制每个用户每秒只能一个请求,如使用guava的RateLimiter在进程限流,故如果多个节点,则每个用户可请求数量实际是节点个数倍;或者通过Nginx将相同的uuid转发到相同的机器上面。

读流量:

  • 页面缓存和页面数据缓存。页面缓存可以是进程缓存,页面数据缓存一般是分布式缓存,保持各节点的数据一致性,如库存数量可以放到分布式缓存中。

降级

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

二、队列削峰

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

入队条件

  • 秒杀的数量有限,所以不需要将第一步限流中成功通过的所有请求都放到队列中,而是可以先将库存数量放到分布式缓存中,如Redis,
    然后先检查库存是否还有,有则扣减库存,因为Redis是单线程的,故是有序,线程安全的,扣减成功,则将该请求放到队列中;
    否则库存不足,直接返回抢购完毕,或者可以优化一下说“抢购完毕,如果有小伙伴放弃,可以继续抢购”来避免队列消息处理失败导致还有没卖完。

请求响应

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

三、服务层异步处理

  • 服务层消费队列的数据,由于此时速度是可控的,故可以起一个后台服务节点即可,消费队列的数据,进行下单操作,递减数据库库存。
  • 如果消费队列的某个数据失败,可以采用fail-fast的原则,直接提示失败,不需要进行重试之类的复杂操作。

四、抢购结果通知

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

1. 客户端轮询

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

2. 消息推送

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

完整架构示意图

在这里插入图片描述

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值