简介基于SpringBoot实现的电商基础秒杀项目适合用于毕业设计、课程设计、期末大作业、工程实训及学科竞赛等场景资源围绕商品秒杀全流程整合前端展示、后端业务逻辑与说明文档代码经过严格测试可直接复现也可作为二次开发的基础模板。 资源包共含2000个文件压缩后大小约53.91MB其中JavaScript脚本有1240个负责交互与动态渲染CSS样式表有357个用于页面布局与美化HTML页面有148个搭建前端结构Java源码有40个实现秒杀核心接口另有113个Markdown文档以及JSON、XML等配置共数十个兼顾讲解、配置与扩展需要使得资源不仅可用于直接运行也便于按模块拆解学习。 目前已有43人浏览学习项目附带设计报告参考答辩评审平均分达到96分功能可靠拿到资料后可快速理解项目结构、复用代码逻辑并在此基础上扩展更多电商功能适合学习练手或直接用于课程与项目交付价值感较强。1. 面向毕设与实训的SpringBoot秒杀项目它到底在解决什么问题秒杀这类SpringBoot项目在毕设、课设和实训里出现频率极高但大多数同学拿到项目后只做了一件事把代码跑起来截几张图放进论文。等到答辩老师问一句“你的库存为什么没超卖”“你的接口并发上限是多少”场面就冷下来了。这个项目标题拆开看其实很直白用SpringBoot做一套电商秒杀链路包含商品、秒杀活动、下单、库存扣减和防超卖。它不追求生产级百万并发但要把秒杀最核心的“库存扣减不能出错、接口不能被刷穿、下单链路不能拖垮数据库”这三件事完整落地。适合什么人做正在准备毕业设计的学生、需要课程设计或实训题目的开发者以及想用“秒杀”作为简历项目去面试初级Java岗位的人。如果你是想学高并发架构的进阶玩家这个项目是入门的桥不是终点。下面从原理、落地、参数和坑四个方向把这个项目完整拆给你。2. 秒杀的核心矛盾库存超卖、接口被刷与SpringBoot里的经典解法2.1 秒杀和普通下单的本质差异三个问题必须同时解决普通电商下单是低并发、重校验系统一天处理几万单已经算有业务量。秒杀不一样它的特征是“短时间、高流量、有限库存”。比如一个商品库存100件开抢后5秒内涌进5000个请求这5000个请求几乎同时到达数据库层。如果代码写的是“先查库存再扣库存”那么并发下会发生典型的超卖10个线程同时读到stock5各自判断“5大于0可以买”然后各自执行update最后库存变成-5订单却生成了10个。这就是秒杀系统第一个要解决的问题库存扣减必须原子化。第二个问题是接口被刷。秒杀接口只要暴露出来脚本可以在1秒内发起上千个请求不走页面、不点按钮直接把你的接口打到超时。所以秒杀接口必须有限流常见做法是令牌桶、漏桶或者Redis计数器。第三个问题是数据库压力。5000个请求如果全部直连MySQL行锁竞争会让数据库CPU瞬间打满整个服务不可用。常规做法是把流量分层先用Redis抗住大部分请求失败的直接在Redis层返回“已抢光”只有少数真正有机会下单的请求才落到数据库。这三个问题不是独立存在的。你只解决超卖、不限流数据库还是会挂你只限流、不解决超卖剩下进来的请求照样可能把库存扣成负数。所以秒杀项目的代码必须同时把这三件事做进去这也是答辩时最容易展开讲的地方。2.2 SpringBoot秒杀项目里的经典分层Redis挡流量、MySQL做最终落库一套在毕设和实训里足够体面的秒杀架构通常只有三层不需要引入微服务、不需要Kafka。第一层是CDN和网关这一层在真实项目里负责静态资源和入口限流在SpringBoot项目里通常去掉直接由拦截器承担限流职责。第二层是Redis层负责热数据读写秒杀商品的库存预热到Redis、用户是否已秒杀过的去重标记、接口访问频率计数全部放在这一层。第三层是MySQL层负责最终落库秒杀商品表、订单表以及真正的事务性库存扣减。Redis层和MySQL层之间的衔接是这套架构的关键。常见做法是“预减库存”请求进来先在Redis执行库存自减减成功了才走后续订单流程减失败直接返回“已抢光”。为什么不让MySQL直接扛因为MySQL的行锁和事务在极端并发下会串行排队5000个请求同时更新同一行不管你的机器多好吞吐量都被压到几百。而Redis是单线程模型INCR/DECR天然原子每秒能扛几万次自减操作正好用来挡流量。但要注意Redis里减掉的库存不一定是最终成交。用户减了库存之后可能下单失败、超时放弃、重复点击所以“Redis预减库存”只能作为一个流量闸门真正的库存扣减和订单创建还是要在MySQL事务里完成。这就是为什么代码里通常要写补偿逻辑MySQL扣减失败时把Redis里的库存加回去。2.3 用RedisLua实现原子预减库存代码级拆解在SpringBoot项目里直接调用redisTemplate.opsForValue().decrement()也能实现自减但有一个边界问题如果库存已经是0decrement会把它减成负数。所以标准的做法要先判断库存是否大于0再执行自减。这两个操作合在一起不是原子的高并发下仍然可能超减。解决办法是用Lua脚本把“判断库存是否足够”和“执行扣减”合并成一个原子操作。Redis执行Lua脚本是整体原子性的中间不会被其他命令插入。下面这段脚本是秒杀项目里最值得抄的代码-- 秒杀预减库存脚本 -- KEYS[1]: 库存key, ARGV[1]: 扣减数量 local stock tonumber(redis.call(get, KEYS[1])) if not stock or stock tonumber(ARGV[1]) then return -1 end redis.call(decrby, KEYS[1], ARGV[1]) return stock - tonumber(ARGV[1])保存为seckill_stock.lua放到resources/scripts目录下SpringBoot侧用DefaultRedisScript加载后执行Configuration public class RedisConfig { Bean public DefaultRedisScriptLong stockScript() { DefaultRedisScriptLong script new DefaultRedisScript(); script.setLocation(new ClassPathResource(scripts/seckill_stock.lua)); script.setResultType(Long.class); return script; } }执行脚本的代码// 返回值大于等于0, 说明预减成功, 返回剩余库存 Long result redisTemplate.execute(stockScript, Collections.singletonList(seckill:stock: goodsId), 1); if (result null || result 0) { return Result.error(已抢光); }这里有三处需要仔细说明。第一KEYS和ARGV不要写死在脚本里要通过参数传入否则每件商品都要生成一份脚本缓存。第二返回值是扣减后的剩余库存如果返回0说明这是最后一件后续请求会拿到-1直接返回失败。第三脚本里没有设置过期时间所以库存key必须在秒杀活动开始前预热时设置好有效期避免秒杀结束后key一直驻留在Redis里。这段脚本解决的是“预减库存”原子性问题。但你要清楚它只管Redis这一层。落库时还有一次库存扣减那一次同样要防超卖解法是在SQL里直接加条件。3. 用IDEA从零搭建SpringBoot秒杀项目建表、分层与下单链路跑通3.1 秒杀业务的最小数据模型三张表加一个唯一索引秒杀项目和你平时写的CRUD最大区别在于表结构设计。常见的电商订单表只有一张order表但秒杀项目通常要拆成三张核心表。第一张是商品表goods存商品基本信息商品名、原价、图片、描述。第二张是秒杀商品表seckill_goods它是秒杀专用的扩展表通过goods_id关联商品表额外存秒杀价、秒杀库存、活动开始时间、活动结束时间。为什么要单独拆一张表而不是在goods表里加字段因为同一个商品可以参与多轮秒杀活动每轮活动的价格和库存不同拆开才能支持这种一对多的关系。第三张是秒杀订单表seckill_order存用户ID、秒杀商品ID、下单时间、支付状态。这张表必须对(user_id, seckill_goods_id)加唯一索引目的是从数据库层面拦截同一个用户重复购买同一件秒杀商品。这段DDL可以直接抄-- 商品表 CREATE TABLE goods ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_name varchar(128) NOT NULL COMMENT 商品名称, goods_price decimal(10,2) NOT NULL COMMENT 原价, goods_img varchar(255) DEFAULT NULL COMMENT 图片地址, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表; -- 秒杀商品表 CREATE TABLE seckill_goods ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_id bigint(20) NOT NULL COMMENT 关联商品表, seckill_price decimal(10,2) NOT NULL COMMENT 秒杀价, stock_count int(11) NOT NULL DEFAULT 0 COMMENT 秒杀库存, start_time datetime NOT NULL COMMENT 活动开始时间, end_time datetime NOT NULL COMMENT 活动结束时间, PRIMARY KEY (id), KEY idx_goods_id (goods_id), KEY idx_start_time (start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT秒杀商品表; -- 秒杀订单表 CREATE TABLE seckill_order ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, seckill_goods_id bigint(20) NOT NULL COMMENT 秒杀商品ID, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付, 1已支付, 2已取消, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, seckill_goods_id) COMMENT 防止重复秒杀 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT秒杀订单表;唯一索引这一行是整个表结构里最值钱的设计。你在答辩时可以说即使应用层幂等判断被绕过数据库唯一约束也会让第二次插入直接抛DuplicateKeyException从最后一道防线挡住重复下单。3.2 创建项目骨架SpringBoot版本选择与起步依赖清单用IDEA创建SpringBoot项目时有个常见纠结版本选新的还是旧的。我的建议是秒杀项目不要追新高用2.7.x这条线最稳。原因很简单网上能找到的秒杀教程、Redis客户端配置、JMeter压测案例绝大多数基于SpringBoot 2.x和javax命名空间SpringBoot 3.x把javax换成了jakarta很多老代码片段直接报错对新手来说等于给自己增加排错成本。在Spring Initializr里勾选下面几个依赖就够了Spring Web提供MVC能力Spring Data Redis提供RedisTemplate和连接池自动配置MyBatis注意不是MyBatis-Plus也行二选一负责SQL映射MySQL Driver连接数据库Lombok省掉getter/setter。如果你后面要接消息队列做异步下单再加Spring AMQP。但项目初期不要贪多依赖越少出问题时排查面越小。创建完成后application.yml里最核心的配置是数据源、Redis和MyBatis三者。一个直接能跑的最小配置如下server: port: 8080 tomcat: threads: max: 300 # 最大工作线程 min-spare: 20 # 最小空闲线程 accept-count: 200 # 等待队列长度 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/seckill?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 hikari: maximum-pool-size: 50 minimum-idle: 10 redis: host: localhost port: 6379 password: lettuce: pool: max-active: 100 # 连接池最大连接数 max-idle: 50 min-idle: 10 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.seckill.entity这些参数不是随手填的每一行都对应着你后面压测的瓶颈点。Tomcat的线程数和accept-count决定了接口能同时处理多少请求HikariCP的maximum-pool-size决定了数据库层能撑住多少并发事务Redis的lettuce连接池限制了访问Redis的并发上限。我后面会单开一章讲压测时怎么根据错误率调整这些值这里先按这套配置跑通项目。3.3 核心下单链路Controller到Mapper的完整代码项目骨架建好后剩下的工作全部围绕一条链路请求进来校验秒杀时间Redis预减库存数据库扣库存创建订单。下面这四段代码构成了整个项目的核心按照Controller、Service、Mapper、XML的顺序贴出来。RestController RequestMapping(/seckill) public class SeckillController { Autowired private SeckillService seckillService; /** * 秒杀接口 * POST /seckill/doSeckill?userId1001goodsId2001 */ PostMapping(/doSeckill) public ResultLong doSeckill(RequestParam(userId) Long userId, RequestParam(goodsId) Long goodsId) { if (userId null || goodsId null) { return Result.error(参数不完整); } return seckillService.seckill(userId, goodsId); } }Controller只做参数校验和结果封装不写任何业务逻辑。这是秒杀项目里很容易被忽略的分层原则很多同学把库存扣减直接写在Controller里代码跑通了但答辩时被问“Service层的作用是什么”就答不上来。Service层是秒杀的核心下面这段代码把预减库存、防重复、落库串在一起Service Slf4j public class SeckillService { Autowired private SeckillGoodsMapper seckillGoodsMapper; Autowired private SeckillOrderMapper seckillOrderMapper; Autowired private RedisTemplateString, Object redisTemplate; Autowired private DefaultRedisScriptLong stockScript; private static final String STOCK_PREFIX seckill:stock:; private static final String USER_BUY_PREFIX seckill:user:; Transactional(rollbackFor Exception.class) public ResultLong seckill(Long userId, Long goodsId) { // 1. 从Redis校验活动时间和用户是否已购买 Boolean bought redisTemplate.hasKey(USER_BUY_PREFIX userId : goodsId); if (Boolean.TRUE.equals(bought)) { return Result.error(您已参加过秒杀); } // 2. Redis预减库存, 原子操作 Long stock redisTemplate.execute(stockScript, Collections.singletonList(STOCK_PREFIX goodsId), 1); if (stock null || stock 0) { return Result.error(已抢光); } try { // 3. 数据库扣减库存, SQL自带stock 0条件, 防超卖 int rows seckillGoodsMapper.deductStock(goodsId); if (rows 0) { throw new RuntimeException(库存扣减失败); } // 4. 创建订单 SeckillOrder order new SeckillOrder(); order.setUserId(userId); order.setSeckillGoodsId(goodsId); order.setStatus(0); seckillOrderMapper.insert(order); // 5. 标记用户已抢购 redisTemplate.opsForValue().set(USER_BUY_PREFIX userId : goodsId, 1); return Result.success(order.getId()); } catch (Exception e) { // 6. 补偿: MySQL扣减失败时, 把Redis预减的库存加回去 redisTemplate.opsForValue().increment(STOCK_PREFIX goodsId); log.error(秒杀失败, userId{}, goodsId{}, userId, goodsId, e); return Result.error(秒杀失败, 请重试); } } }public interface SeckillGoodsMapper { int deductStock(Param(goodsId) Long goodsId); }update iddeductStock UPDATE seckill_goods SET stock_count stock_count - 1 WHERE id #{goodsId} AND stock_count 0 /update上面这段代码里有三个地方必须结合执行顺序说明白。第一Redis预减成功后MySQL扣减失败会走catch分支把Redis库存加回来这一步是保证Redis和MySQL一致性的兜底手段。第二deductStock的SQL里带了AND stock_count 0条件这一步是数据库层的最终防线即使Redis被绕过、即使并发穿透到了MySQL条件更新也会让超卖在SQL层面失败。第三用户已购标记是在事务提交前写入Redis的存在一个极小的时间窗口事务回滚了但Redis标记已写入。不过以秒杀项目的体量这个窗口可以忽略真正要追求严格一致时应该把标记写入放在事务提交后。还有一个细节值得单独讲Transactional注解下catch里捕获了异常事务不会自动回滚。上面代码里扣减失败抛了RuntimeException但被catch捕获后事务仍然可能提交。正确的做法有两种要么把redisTemplate.opsForValue().increment()和订单失败处理放在事务之外要么抛出一个自定义异常并让事务管理器捕获回滚。在秒杀这个场景里推荐前一种做法数据库扣减成功后立刻提交事务Redis补偿放在事务提交后的finally里执行。你可以按这个思路把第6步改成事务同步回调下文的避坑章节会给出具体写法。4. 把接口压到不翻车限流配置、连接池参数与JMeter压测方法4.1 限流是秒杀接口的第一道防线基于Redis计数器的拦截器秒杀接口一旦上线测试工具、爬虫脚本、黄牛软件都会盯上它。如果你的接口没有任何限流措施1000个并发直接打到Tomcat即使Redis能扛住Tomcat线程池和数据库连接池也会先撑不住。所以限流不是锦上添花是秒杀项目的必备功能。限流算法里令牌桶适合处理突发流量漏桶适合平滑流量但对秒杀这种场景最简单可靠的是固定窗口计数器同一个用户在1秒内最多允许请求N次超过直接拒绝。用Redis的INCR命令配合过期时间就能实现下面是拦截器的完整代码Component public class RateLimitInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, Object redisTemplate; private static final String LIMIT_PREFIX seckill:rate:; private static final int MAX_REQUESTS_PER_SECOND 5; // 每用户每秒最多5次 Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String userId request.getParameter(userId); if (userId null) { response.setStatus(400); return false; } String key LIMIT_PREFIX userId; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1L) { // 第一次计数时设置过期时间, 窗口为1秒 redisTemplate.expire(key, 1, TimeUnit.SECONDS); } if (count ! null count MAX_REQUESTS_PER_SECOND) { response.setStatus(429); // Too Many Requests return false; } return true; } }这个拦截器有个实现细节要注意INCR和EXPIRE不是原子的如果第一次INCR之后、设置EXPIRE之前进程崩溃这个key就永远不会过期。更稳妥的写法是改用Lua脚本把INCR和EXPIRE合并成一个原子操作或者直接用Redis的SET NX EX命令做计数器初始化。秒杀项目里用拦截器的方案已经足够但你心里要清楚这个边界答辩被问到“你的限流有没有原子性问题”时能答出第二层。4.2 必调的6个参数Tomcat线程池、HikariCP、Redis连接池与JVM跑通代码只是第一步秒杀项目真正花时间的环节是压测和调参。很多同学发现自己本地跑得好好的用JMeter一压就大量报错原因不是代码有问题而是SpringBoot默认参数扛不住并发。下面这张表是我做秒杀项目时按照压测结果反复调出来的参数组合可以直接对照修改配置项默认值秒杀推荐值为什么这么调server.tomcat.threads.max200300默认200个线程在1000并发下直接排队server.tomcat.accept-count100200排队队列长度太短会直接拒绝连接spring.datasource.hikari.maximum-pool-size1050默认10个数据库连接是秒杀最大瓶颈spring.datasource.hikari.minimum-idle1010保持最小空闲连接避免冷启动spring.redis.lettuce.pool.max-active8100默认8个Redis连接, 高并发下不够用spring.redis.lettuce.pool.max-idle850配合max-active减少连接创建开销JVM参数里最常见的调整是堆内存IDEA里直接跑的话默认堆通常只有256MB压测时频繁Full GC会把CPU耗尽。在启动参数里加-Xms512m -Xmx512m是最低配置毕设演示机器上加到1G更稳妥。注意堆内存不要无脑加大512M到1G对秒杀场景足够再大会拖慢启动速度。一个很容易被忽略的参数是MySQL的max_connections。默认值是151HikariCP的50个连接加其他应用占用在压测时很容易把MySQL连接数打满。建议在MySQL配置文件里调高到500以上同时把HikariCP的maximum-pool-size控制在50以内留出余量给管理工具。以上参数不是玄学每一条都能在压测报告里找到对应现象。比如Tomcat线程数太小报错信息是Connection reset或者SocketException数据库连接池太小报错是HikariPool-1 - Connection is not available, request timed outRedis连接池太小报错是RedisConnectionFailureException。记住错误信息和参数的对应关系排错速度会快很多。4.3 用JMeter压测一轮线程组参数设置与结果解读压测工具我推荐JMeter开源、免安装、支持图形化配置。压测秒杀接口时按下面这套参数设置线程数500Ramp-Up周期5秒循环次数10。即5秒内启动500个线程每个线程连续请求10次总请求量5000。启动压测后重点看聚合报告里的三列Error%、Average、Throughput。Error%超过0说明有请求失败需要去查看响应体里的错误原因Average是平均响应时间秒杀接口在300ms以内算健康超过1秒说明有严重瓶颈Throughput是每秒吞吐量这个数字直接决定了你项目答辩时能说“支持多少并发”。压测过程中要同时观察服务端状态。Windows下用JDK自带的jconsole连接本地Java进程看堆内存和GC曲线Linux下用top命令看CPU占用。如果压测时CPU持续100%但吞吐量上不去大概率是发生了大量GC或者Redis连接等待。第一次压测的结果通常会很难看这很正常。拿着错误信息回到4.2的参数表逐项调整然后重新压测记录前后对比。这一组前后数据就是你论文里的实验章节也是答辩时最有说服力的内容。5. 秒杀项目必踩的5个坑现象、原因与修复记录5.1 并发1000下库存变负数超卖问题修复记录现象用JMeter开500线程压秒杀接口压完之后查数据库库存变成负数订单数大于库存数。原因Mapper里的update语句写成了先查库存再更新或者update没有带stock_count 0条件。解决把SQL改成条件更新这是最彻底的修复方法。我在3.3节已经给出标准写法这里补充一个验证方法压测完成后执行下面这条SQL如果查询结果为空说明没有超卖。-- 检查超卖: 只要有返回行就是出问题了 SELECT * FROM seckill_goods sg LEFT JOIN seckill_order so ON so.seckill_goods_id sg.id WHERE sg.stock_count 0;5.2 一压测接口就大量Connection resetTomcat线程池被瞬间打满现象本地单请求一切正常JMeter一开500并发聚合报告里大量Connection reset服务端日志没有异常堆栈。原因Tomcat默认的maxThreads200accept-count100500并发瞬间涌入时超过300个连接直接被拒绝。解决按4.2的推荐值调大server.tomcat.threads.max和accept-count。这里有一个前提调大线程池只会放大系统吞吐上限不会解决数据库连接池不够的问题。如果你只调Tomcat不调HikariCP瓶颈会立即转移到数据库层报错变成连接等待超时。所以这两项必须同步调整。5.3 Redis预减了库存但数据库没扣成功库存数据对不上现象Redis里的库存已经减到0但数据库的seckill_goods表库存还剩几十件用户看到“已抢光”但后台还有余量。原因代码在Redis预减成功之后MySQL扣减失败抛了异常但没有把Redis的库存补偿回来或者补偿代码写在事务方法内部、事务回滚后补偿逻辑没执行上。解决把Redis补偿放到事务状态同步回调里执行。改造方式让SeckillService注入TransactionTemplate用编程式事务替代Transactional在事务提交成功后执行Redis回补。事务提交失败时由于库存原本就没扣成Redis回补也无需执行。如果你不想改造事务方式至少要把catch里的redisTemplate.increment写到事务边界之外比如用TransactionSynchronizationManager注册afterCommit回调。5.4 SpringBoot版本太高导致Redis连接池配置不生效现象application.yml里配置了lettuce.pool.max-active100但压测时报错“Unable to connect to Redis, connection pool exhausted”。原因SpringBoot 3.x把javax.sql迁移到了jakarta.*同时Lettuce连接池相关配置的自动装配逻辑有变化网上大量2.x的教程配置在3.x下不生效最常见的是缺少commons-pool2依赖。很多人在pom.xml里只引入了spring-boot-starter-data-redis这个starter默认不引入连接池实现你在配置里写了max-active它也不起作用Lettuce会退化成单连接模式。解决在pom.xml里手动加org.apache.commons.commons-pool2依赖或者干脆按我前面的建议秒杀项目用SpringBoot 2.7.x避开这个系列问题。5.5 用户重复秒杀同一商品幂等没拦住现象同一个用户用脚本并发请求秒杀接口10次生成了多笔订单。原因Service层判断“用户是否已购买”用了Redis的hasKey但Redis标记是在订单插入之后才写入的并发请求在标记写入前全部通过了判断。解决三层防线缺一不可。第一层是Redis预减库存的Lua脚本让同一用户串行化第二层是数据库唯一索引uk_user_goods重复插入直接抛DuplicateKeyException这是最可靠的防线也是修复这个问题的核心第三层才是应用层的hasKey判断。修复后再次用JMeter模拟同一用户并发10次请求最终订单表里该用户对该商品只有一条记录。6. 进阶与答辩准备把单机秒杀向分布式演进用压测数据撑住论点6.1 单机到分布式的三步演进路径秒杀项目能跑通并发压测之后你手里其实已经有一套完整的代码资产。如果想在课设、实训或者面试里再进一步可以直接按下面三步演进每一步都有明确的验证标准。第一步是把下单操作改成异步Redis预减库存成功后不直接落MySQL而是把订单消息丢到RabbitMQ或RocketMQ的消息队列由消费者异步创建订单。这一步能显著降低数据库瞬时压力压测吞吐量会因此翻倍。验证方法是压测期间看MySQL的TPS曲线数据应该像一条平缓的直线而不是脉冲式的尖峰。第二步是引入Redis主从复制或者哨兵模式解决单点问题。项目里所有Redis读写走masterslave作为备份。验证方法手动kill掉master进程观察服务是否自动切换到slave。这一步不复杂但能让你的项目从“能跑”变成“可运维”。第三步是把MySQL拆成读写分离秒杀商品库存的写入只走主库查询走从库。这一步要引入数据库中间件或者Spring的多数据源配置工程量和踩坑量都明显增大。到这一步你的项目已经足够作为简历上的高并发项目经验了。6.2 用压测数据为答辩准备一张对比表答辩时老师不一定看得懂你的代码但他一定能看懂对比数据。建议你在交项目之前做三组压测整理成表格第一组是没有任何优化、直连数据库的版本记为基线第二组是加了Redis预减库存和限流的版本第三组是加Listener异步下单的版本。三组用同样的JMeter配置500线程、5秒Ramp-Up、每线程循环10次。表格记录Throughput, Error%, 平均响应时间三列。通过三组数据你能在答辩时讲清楚一个完整的优化故事基线版本有多少并发会超卖和超时、Redis挡流量后吞吐量提升多少、异步削峰后数据库压力下降多少。这比任何架构图都有说服力。最后说一个我自己的教训我第一次做秒杀项目时只顾着把代码跑通把Redis预减库存和数据库扣减的顺序写反了先用数据库扣库存再写Redis答辩老师一压测数据库直接被打挂。后来才明白秒杀项目里每一步操作背后都有明确的流量和一致性考量不是代码能跑就完了。希望这个项目的拆解能帮你把每一步的原理在动手前先想清楚少走我踩过的弯路祝你的毕设或课设顺利。如果你做的是前后端分离版本可以顺手把管理后台的订单列表接一个MyBatis分页插件秒杀接口保持独立别让后台查询影响秒杀链路的性能。这又是一个能在答辩里讲的细节希望帮到你。本文还有配套的精品资源点击获取