java电商系统怎么设计秒杀?

发布于:2023-01-20 ⋅ 阅读:(5) ⋅ 点赞:(0) ⋅ 评论:(0)

秒杀活动是指网络商家为促销等目的组织或网上限时抢购活动,这种活动具有瞬时并发量大、库存量少和业务逻辑简单等特点。设计一个秒杀系统需要考虑的因素很多,比如对现有业务的影响、网络带宽消耗以及超卖等因素。本文会讨论秒杀系统的各个环节可能存在的问题以及解决方案。

开源实战项目 新零售电商 saas 系统weiit-saas: weiit-saas是一款Java开源项目,属于weiit团队自研产品,意在通过技术封装,让企业无需代码开发,帮助企业一键生成小程序、公众号,让企业拥有独立品牌的自营商城。

秒杀系统

傻瓜式秒杀系统

秒杀系统的核心难点是并发量,如果不考虑并发问题,那么我们可以用如下图所示的简单的系统结构来实现秒杀系统,用户只有两个简单操作:刷新界面和秒杀按钮,服务端也只有两个服务接口:返回秒杀界面和处理秒杀逻辑。假设本文中秒杀商品有 100 个,参与秒杀的用户有 100w 个。

但是在高并发场景下,这个系统会有很多问题,我们全文会针对这些问题一一进行优化

  1. 大量用户同时刷新界面,会对服务器的带宽造成非常大的压力;

  2. 用户在秒杀前后可以多次重复点击按钮,造成很多不必要的请求;

  3. 用户可以通过脚本进行抢购,并且抢购成功率非常高;

  4. 服务端承受高并发请求,会出现响应过慢或失败等情况;

  5. 数据库承受高并发请求,会导致连接池耗尽和响应缓慢;

  6. 如果数据库更新设计得不合理,可能会出现超卖的情况;

秒杀界面 CDN

秒杀开始之前,用户都会请求秒杀界面,有的用户甚至会不断地刷新秒杀界面,100W 用户可能产生上千万次秒杀界面请求。秒杀界面往往包含很多静态资源,如果这些界面请求全部通过服务器获取,会造成大量的带宽消耗,甚至造成秒杀还没开始服务器就崩了的情况。

对于网页这种静态资源的并发访问,业内早就有成熟的解决方案:内容分发网络 (CDN)。我们可以在秒杀开始前,预先把网页的静态资源存放在 CDN 节点,用户在刷新界面时直接从 CDN 获取静态资源,从而降低刷新秒杀界面对服务器造成的压力。添加了 CDN 服务之后,秒杀界面有大量用户同时访问和刷新并不会给服务端带来多大压力。

秒杀按钮优化

我们知道,秒杀系统往往会有一个秒杀按钮,如果不对按钮进行限制,可能存在以下问题:

  • 用户在秒杀开始前点击按钮,造成很多无用的请求;

  • 用户在秒杀开始后多次点击按钮,造成很多重复请求;

所以我们可以对按钮做一些限制:秒杀开始前按钮不可用,用户点击一次秒杀按钮后,按钮也进入不可用状态。这种方式无法限制通过脚本请求后端的情况,但是可以限制正常用户的多次无效点击,大大降低请求量。

秒杀链接优化

普通情况下,用户在点击秒杀按钮的时候,前端会请求一个固定的 URL,这个 URL 可以在前端界面查到。对于普通不懂技术的用户来说,这没有什么问题,如果用户稍微懂点 Http 协议,就可以在秒杀开始前拿到 URL,在秒杀开始前或开始的毫秒级时间内请求秒杀链接,不仅会给服务端带来很大的压力,还会造成不公平现象:商品都被开脚本的人抢走了。

为了避免这种现象,我们可以将 URL 动态化,即使秒杀系统的开发人员也无法在知晓在秒杀开始时的 URL。具体实现方法是在获取秒杀 URL 的接口中,返回一个服务器端生成的随机数,并在下单 URL 中传递该参数完成下单。

秒杀验证码

虽然说我上面通过动态 URL 避免了用户在秒杀开始前请求秒杀链接,但是用户还是可以通过脚本在秒杀开始的那一刻去请求秒杀连接,普通用户基本没有办法和脚本秒杀进行竞争。

我们可以引入机器难以识别的验证码,用户在请求秒杀链接之前,需要填写验证码识别的结果,验证码错误的请求直接拒绝。使用验证码不仅可以增加脚本秒杀的难度,还可以降低请求的 QPS,因为请求不再是在秒杀那一刻进来,而会被分散到填写验证码的时间段内。

过滤请求

通过上面的步骤,我们可以减少很多重复请求和脚本请求,可以保证秒杀活动中一个人大致只会请求一次 (脚本还是可以请求多次)。但是 100W 人参与秒杀,每人请求一次秒杀链接也有将近 100W 次请求,服务器还是扛不住。

仔细分析之后可以发现,秒杀的商品只有 100 个,最后成功的也只有 100 个,那么我们 100W 的请求是不是都有必要请求到秒杀服务器上呢?显而易见,我们没有必要把所有请求都打到秒杀服务器上,我们只需要保证有大于 100 个请求打到秒杀服务器就可以保证秒杀的正常进行,所以我们可以在用户端和服务端添加一层过滤层,过滤层只要保证有 100 个以上的请求能打到秒杀服务器端。

我们可以使用 Nginx 服务器来构建过滤层,一个 Nginx 服务器也没法抗 100W 的请求,我们假设每个 Nginx 服务器可以处理 10W 的请求,那么我们就需要 10 台 Nginx。那么怎么用保证至少有 100 个请求可以请求到后端呢?我们可以简单的让每个 Nginx 服务器只通过前 100 个请求,后续请求直接返回降级界面。通过 Nginx 过滤,我们可以把 100W 的请求过滤为 1000 个请求,大大减少了服务器端的压力。

Redis 缓存

如果通过前面的过滤,请求量依旧非常大,如果数据库无法处理这些请求量,我们就需要在数据库之上添加一层 Redis 缓存了。单个 Redis 可以处理几万的 QPS,如果预估请求的 QPS 大于几万,我们还可以使用 Redis 集群模式来增加 Redis 的处理能力。

在 Redis 存放和售卖商品数目大小相同的数字,秒杀服务每次访问数据库之前,都需要先去 Redis 中扣减库存,扣减成功才能继续更新数据库。这样,最终到的数据库的请求数目和需要售卖商品的数目基本一致,数据库的压力可以大大减少。

Redis 原子性

我们知道 Redis 是不支持事务的,所以可能出现扣减为负数的情况,这种情况下我们可以使用 Lua 脚本来保证一次扣减操作的原子性,从而保证扣减结果的正确性。

异步更新数据库

通过 Redis 判断之后,去更新数据库的请求都是必要的请求,这些请求数据库必须要处理,但是如果数据库还是处理不过来这些请求怎么办呢?

这个时候就可以考虑削峰填谷操作了,削峰填谷最好的实践就是 MQ 了。经过 Redis 库存扣减判断之后,我们已经确保这次请求需要生成订单,我们就可以通过异步的形式通知订单服务生成订单并扣减库存。


网站公告

欢迎关注微信公众号

今日签到

点亮在社区的每一天
签到