技术关-服务器--2-CSDN博客

本文链接：https://blog.csdn.net/fengfeiyeqi/article/details/136490743

文章详细探讨了秒杀系统架构设计的关键问题，包括超卖防范、恶意请求处理、数据库压力、缓存管理、高可用性保障以及前端限流等。作者强调了在面对大量用户涌入时如何保证系统性能和可用性，以及如何通过技术手段如Redis、MQ和数据库设计来解决挑战。

摘要由CSDN通过智能技术生成

4.2 秒杀的系统架构设计

本节点需要用的计算公式就要考虑利用

用户量： 10w

公式 : 1 ）平均并发用户数为 C = nL/T 2 ）并发用户数峰值 C‘ = C + 3* 根号 C 3 ）并发量除响应时间 = qps

4.2.1. 思考问题思考因素

短小彪悍问题多

持续性短 ---》短时间内的活动
速度快 ---》程序的处理必须要快
量又大 ---》会存在大量的用户涌入
又简单 ---》是指业务流程简单；基本流程上就是，判断库存->减库存->下订单
命中少 ---》不能出现超卖，比如100w用户购买抢购，商品库存只有100件，那就只能卖出100件
读多写少 ---》项目访问基本上都是以读为主要的操作，写相对较少

总结：说白了还是高并发、高可用、高性能怎么整 ;

有一点不同的是；我们还需要考虑风险，黄牛

4.2.2. 秒杀要考虑的问题

1. 关键问题：超卖

那个系统秒杀要是超卖了那就比较亏了，本身秒杀是亏的考的就是多销盈利；要是秒杀的商品是 MacBook Pro 系列等，那就血亏了；

2. 来历不明：恶意请求、黄牛

树大招风、低价格适宜的都是比较吸引人的；因此总有恶意破坏的、暗中当黄牛的很多；混淆在真实的用户群里面难以分辨

3. 太暴露了：链接没有处理好直接暴露出来

但凡了解程序的都知道 f12 ，就可以看到 html 页面， url 更是无所遁形 ; 爬虫同学不就可以写一个程序疯狂抢购了嘛

4. 数据库：太脆弱、容易挂

数据库在上万甚至上十几万的 QPS 的时候，根本扛不住；特别脆弱像一张纸一样；

5. 缓存流量集中

运用 Redis 之后，如果不做好处理也会流量集中在一台机器上；这样就会造成流量集中访问， redis 集群的效果就没用好（主从可以在程序层面负载均衡）

6. 高可用的细节

注意各个节点都有可能存在宕机的问题，因此在各环节上需要注意

4.2.3.秒杀的流程

秒杀的主要业务环节有

用户发起秒杀请求 - 》验证码是否正确（前端验证） - 》限流 - 》风控 - 》判断活动是否结束 - 》缓存库存是否足 - 》扣除缓存库存- 》根据秒杀商品信息生成订单返回 - 》提交订单 - 》订单入库 - 》减真实库存 - 》成功

1. 用户发起秒杀请求

在同步下单流程中，首先，用户发起秒杀请求。商城服务需要依次执行如下流程来处理秒杀请求的业务。

（ 1 ）识别验证码是否正确

商城服务判断用户发起秒杀请求时提交的验证码是否正确。

（ 2 ）判断活动是否已经结束

验证当前秒杀活动是否已经结束。

（ 3 ）验证访问请求是否处于黑名单

在电商领域中，存在着很多的恶意竞争，也就是说，其他商家可能会通过不正当手段来恶意请求秒杀系统，占用系统大量的带宽和其他系统资源。此时，就需要使用风控系统等实现黑名单机制。为了简单，也可以使用拦截器统计访问频次实现黑名单机制。

（ 4 ）验证真实库存是否足够

系统需要验证商品的真实库存是否足够，是否能够支持本次秒杀活动的商品库存量。

（ 5 ）扣减缓存中的库存

在秒杀业务中，往往会将商品库存等信息存放在缓存中，此时，还需要验证秒杀活动使用的商品库存是否足够，并且需要扣减秒杀活动的商品库存数量。

（ 6 ）计算秒杀的价格

由于在秒杀活动中，商品的秒杀价格和商品的真实价格存在差异，所以，需要计算商品的秒杀价格。

注意：如果在秒杀场景中，系统涉及的业务更加复杂的话，会涉及更多的业务操作，这里，我只是列举出一些常见的业务操作。

2. 提交订单

（ 1 ）订单入口

将用户提交的订单信息保存到数据库中。

（ 2 ）扣减真实库存

订单入库后，需要在商品的真实库存中将本次成功下单的商品数量扣除。

4.2.4.秒杀设计

结构体：

流程图：

在如上流程主要是针对秒杀的过程，当然开始前后没有做细节的绘制到图上；会在后面补充；以秒杀1000的商品为例

1. 前端页面

在秒杀前我们需要先考虑前端的页面；

页面静态化：将需要秒杀的商品转为静态化（可以根据页面的实际情况划分不同的唯度存储在缓存中），在秒杀环节中可提前放入到CDN服务器中
按钮控制：注意秒杀前一秒用户会狂点，往死里点，还是物理外挂的点击（没错说的就是你）；应对在秒杀开始前先按钮置灰，在到时间点了也再灰几秒，避免到时间点集中点击（到时间点击停不下来）
前端限流：在点击一次按钮之后，需要过几秒钟才能继续点击，不能连续点击

-- 》流量可以砍去一部分

2. 地址保护

一般做网页的开发者，默认都会选择对外提供，自己项目的 url （就是你）；懂得 f12 的小伙子们都知道怎么去查 url 地址，这个时候如果后台的请求被黄牛、黑客发现；那么这是一个非常危险的存在（对于超具有诱惑力的商品来说）

连接保护：可以将url动态化，可基于MD5的方式加密再处理之后的字符串去作为url，前端只需要通过前端代码获取url后台校验才能通过

爬虫的高级：就是 js 的逆向算法的破解

-- 》流量可以砍去一部分 , 针对不正当手段的

3. nginx

负载均衡: 在nginx中也可以增加负载均衡，进行分流
限流：拦截恶意的流量利用limit的方式可以控制，再可以基于lua结合Redis再进一步的提升限流功能

-- 》又一次再砍，这里可以放出 1w 的流量；因为需要保持有真实的用户（后台准备处理多少并发）

4. 风控

这一层的话要看你们公司的情况来选择，因为风控的方式可以购买产品去实现；当然也可以自己去实现需要利用到人工智能的深度学习

-- 》再砍掉不正常的流量，直接通杀

5. 后端服务

尽量职责打印：针对秒杀我们往往可以选择单独构建出一个秒杀的服务，其中代码可以复用之前正常的业务流程的代

码；

职责单一：在秒杀中需针对性的构建、秒杀服务
业务隔离：从业务上需要把秒杀和日常的售卖商品进行区分，针对需要进行秒杀的商品，提前申请并根据商品提前生成静态页面上传到CDN中，讲商品库存在活动开始前也预热到Redis中
择优选择：在秒杀期间也可以考虑针对一些用户访问并不是很高的功能可以先限流，优先应对好秒杀的业务如某宝
部署隔离：秒杀相关的服务和日常服务要分组部署，不能因为秒杀出问题影响正常的业务服务
高可用：集群，微服务，分布式

6. redis

秒杀的本质实际上就是对库存的抢夺；

预热：提前将需要秒杀的商品写入到数据库中，在秒杀结束了再异步修改数据库中的库存
高可用：主从+哨兵：如果是利用主从的话需要自己在程序中实现好对应的读写分离，从节点的负载均衡集群：如果是集群我们就需要考虑问题，可能会集中写入访问；建议可以对秒杀的库存进行划分 id_1,id_2,id_3这样的方式划分库存可让iD能够分散到Redis的集群的各个节点上，有理由读写的负载均衡
事务-锁：Redis本身是支持事务，在用的时候可以考虑是利用管道，乐观锁，分布式锁来避免超卖问题