java信用分秒杀系统设计思路,秒杀系统设计思路

一、限流与降级

客户端限流

按钮置灰

js控制每秒只能发送一个请求

站点层限流

1. Nginx限流

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

limit_req_zone: 用来限制单位时间内的请求数,即速率限制,采用的漏桶算法。

limit_req_conn: 用来限制同一时间连接数,即并发限制。

2. 站点层限流

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

写流量

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

读流量:

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

降级

如果流量太大,导致站点层限流后还是出现问题挂了或者站点层没问题,队列出问题了,则需要采取降级策略。

对于站点层出问题,则可以在客户端直接提示“服务器繁忙,稍后再试”。

对于队列挂了或者Redis挂了无法读取到库存信息,则可以在站点层降级处理,直接返回和提示“抢购人数太多,请稍后尝试”。

二、队列削峰

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

入队条件

秒杀的数量有限,所以不需要将第一步限流中成功通过的所有请求都放到队列中,而是可以先将库存数量放到分布式缓存中,如Redis,

然后先检查库存是否还有,有则扣减库存,因为Redis是单线程的,故是有序,线程安全的,扣减成功,则将该请求放到队列中;

否则库存不足,直接返回抢购完毕,或者可以优化一下说“抢购完毕,如果有小伙伴放弃,可以继续抢购”来避免队列消息处理失败导致还有没卖完。

请求响应

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

三、服务层异步处理

服务层消费队列的数据,由于此时速度是可控的,故可以起一个后台服务节点即可,消费队列的数据,进行下单操作,递减数据库库存。

如果消费队列的某个数据失败,可以采用fail-fast的原则,直接提示失败,不需要进行重试之类的复杂操作。

四、抢购结果通知

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

1. 客户端轮询

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

2. 消息推送

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

完整架构示意图

60319f5f4167

秒杀.png

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值