如何测试一个秒杀系统

秒杀系统=压力测试

先从开发角度了解一下秒杀系统如何实现

• 前端：处理用户请求，展示秒杀页面。
• API 网关：负责请求路由和限流。
• 秒杀服务：处理秒杀逻辑。
• 库存服务：管理商品库存。
• 数据库：存储商品和用户数据。
• 缓存：用于加速读取操作和减少数据库压力。
• 消息队列：用于异步处理和削峰填谷。
• 分布式锁：确保并发控制和数据一致性

先从服务端去考虑理解

ApI网关的在秒杀系统中主要保证服务端稳定，说白了就是防止服务器崩掉，既然是保护就要进行限流和熔断

限流熔断：设置每秒的请求数量 1s 8000并发 第8001以及以后的请求会被舍弃掉  舍弃掉的请求接口请求返回状态码503 服务器无法处理请求

负载均衡概念：负载均衡的基本原则是尽可能均匀地分配流量到后端的多个服务器，避免某一台服务器成为瓶颈。常用的流量分配策略包括

第一点：平均分配流量

四种实现方法：1、轮询 2、加权轮询 3、最少连接 4、源地址哈希

1. 轮询：按照顺序分配 比如四台服务器 并发8个请求 第一天服务器会受到15请求
2. 加权轮询：每个服务器按照权重分配 就是cpu处理能力 好的cpu多分点请求  这就是这个方法优点，在工作中可能不同批次购买的服务器cpu不同 就可以根据能者多劳的原则分配
3. 最少连接：谁的请求最少给谁处理
4. 源地址哈希：根据IP地址去分配请求 缺点可能会被一个IP地址使用科技大量并发请求导致服务器打满 容易被攻击需要应答机制

第二点：高可用性

如果出现一台服务器故障自动转移到另外一台服务器上

实现思路：健康检查和故障转移 （不延深感兴趣自己查）

第三点：性能

1、简单直接的方式加服务器，可以购买一些短期服务器 秒杀当天增加服务器数量 活动结束下掉

2、缓存机制：redis 接口请求比较频繁的数据打到redis的服务器上  200 缓存获取成功 204缓存删除成功 404 缓存未找到 410 缓存过期需重新拉取 201服务端有变化 拉去服务端数据并更新成功

消息队列：异步设计、请求永久储存、失败重试机制

LJP做饭为例：

同步：洗菜10分钟→淘米煮饭10分钟→起锅烧油10分钟→炒菜10分钟 总共花费了40分钟

异步：来了2个帮手 前三步总共花了10分钟 一共花了20分钟

分布式锁：理解待补充  主要通过代码进行测试验证 

测试场景

• 互斥性：验证在同一时刻只有一个客户端能持有锁。
• 加锁和解锁：验证客户端能成功加锁和解锁。
• 锁的过期时间：验证锁在超过过期时间后自动释放。
• 死锁检测：验证系统能正确处理死锁情况。

1、熔断机制测试 并发8010 成功8000次 10次请求失败错误状态码503

2、熔断的请求接口返回状态码503 前端是否根据状态码给用户错误提示 UX测试

3、单接口请求一次响应时间不应该大于100ms 大于100ms讨论是否合理 如果是查询能否进行sql优化/表结构优化/是否有索引

4、异步函数调用：能否正常执行并返回预期结果（代码测试）

5、回调函数执行：验证异步函数正确后能否顺利执行回调函数（代码测试）

6、性能测试：下一篇讲