简介高并发系统设计是后端开发的核心挑战之一其核心原理在于通过架构手段应对瞬时流量洪峰保障系统稳定。技术价值体现在通过分层设计、缓存策略和异步处理在有限的资源下最大化系统吞吐量与可用性。典型的应用场景包括电商秒杀、票务抢购等瞬时高并发业务。本文以SpringBoot和MySQL为基础技术栈深入剖析了如何利用Redis缓存进行库存预热和原子扣减并结合消息队列实现异步订单处理从而有效解决超卖问题平滑数据库压力构建一个高性能、高可用的秒杀系统。1. 项目概述与核心价值最近在整理硬盘翻出来一个几年前参与过的商城秒杀系统源码包。这个项目在当时算是一个比较典型的“高并发、高性能”实战案例麻雀虽小五脏俱全。今天正好借这个机会把这个基于 SpringBoot Mybatis MySQL 的秒杀系统从架构设计到代码实现的里里外外给大家掰开揉碎了讲一讲。无论你是想学习如何应对瞬时流量洪峰还是想了解一个完整电商后端核心模块的构建这个项目都能给你提供不少直接的参考。秒杀说白了就是在极短的时间内比如几秒钟将少量极具吸引力的商品比如特价手机、限量球鞋卖给海量的用户。这听起来简单但技术挑战巨大瞬时超高并发、有限的库存、绝对的公平性、以及防止系统被压垮。这个源码项目就是围绕这些核心挑战展开的。它没有用到特别“黑科技”的组件而是基于当时现在依然主流的技术栈通过合理的架构分层、缓存策略、异步处理和数据库优化构建了一个能扛住一定压力、保证核心流程正确的系统。对于想从 CRUD 进阶到高并发系统设计的开发者来说这是一个非常好的练手和学习的样本。2. 系统架构设计与核心思路拆解拿到一个秒杀系统我们首先要思考的不是写代码而是设计。核心思路就一句话将大部分请求拦截在系统上游让尽可能少的请求穿透到数据库。2.1 分层削峰与流量控制一个未经优化的秒杀流程是用户点击“立即抢购” - 请求直达应用服务器 - 应用服务器查询数据库库存 - 扣减库存 - 创建订单。这在万人同时点击的瞬间数据库连接池会被瞬间打满轻则响应缓慢重则直接宕机这就是所谓的“雪崩效应”。这个项目的架构采用了典型的分层削峰策略前端层面按钮防重复提交前端JS控制点击后置灰、倒计时校准避免用户本地时间不准导致提前请求、随机化请求路径增加脚本攻击难度。网关/负载均衡层虽然这个 demo 项目可能没集成但在真实场景中这一层会进行限流如 Nginx 的limit_req模块、恶意 IP 封禁。应用层我们的 SpringBoot 服务这是核心防护阵地。我们采用令牌桶或漏桶算法进行限流确保进入核心业务逻辑的请求速率是可控的。例如使用 Guava 的RateLimiter或集成 Sentinel 组件。缓存层这是扛住瞬时流量的王牌。商品库存信息提前预热到 Redis 中所有的库存查询和预扣减都在内存中进行速度极快。数据库层经过前面几层的过滤到达数据库的写请求最终扣减库存、创建订单已经大大减少。我们通过消息队列异步化和数据库事务优化来平稳处理这些请求。注意限流不是为了拒绝用户而是为了保护系统。被限流的请求应该获得友好的提示如“活动太火爆请稍后再试”而不是一个冷冰冰的 500 错误。2.2 技术栈选型背后的考量SpringBoot作为微服务时代的“快速启动器”它简化了配置让我们能快速搭建一个可独立运行、内嵌 Tomcat 的 Web 应用。它的自动配置、Starter 依赖和 Actuator 监控端点对于需要快速迭代和部署的秒杀场景非常友好。Mybatis相比 JPA 的全自动化Mybatis 提供了更灵活的 SQL 掌控能力。在秒杀这种对数据库操作性能极其敏感的场景我们往往需要编写高度优化的 SQL甚至使用一些数据库特定的语法。Mybatis 的 XML 配置或注解方式能让我们清晰地管理和优化这些 SQL。MySQL关系型数据库的绝对主流事务保证ACID是秒杀公平性和数据一致性的基石。虽然最终会引入缓存但库存和订单的“唯一真理源”必须落在数据库上。中间件Redis RabbitMQ/RocketMQRedis扮演缓存和分布式计数器的角色。存储秒杀库存、用户秒杀资格标记防重复购买、以及热点数据。其单线程内存操作模型在高并发读场景下性能卓越。消息队列MQ扮演异步处理器和流量缓冲区的角色。用户秒杀成功的请求并不直接同步创建订单和扣库而是发送一个消息到 MQ。由后台的订单服务消费者异步处理。这能将耗时操作写库、发短信与用户请求响应解耦极大缩短前端响应时间并平滑数据库写入压力。这个技术栈组合是在性能、开发效率、可控性和社区成熟度之间取得的一个经典平衡。3. 核心模块解析与实现要点让我们深入到代码内部看看几个最关键的部分是如何实现的。3.1 商品与库存模型设计库存是秒杀的核心。在数据库里我们至少需要两张表seckill_goods(秒杀商品表)包含商品ID、原价、秒杀价、初始库存、开始时间、结束时间等。seckill_stock(秒杀库存表)这是一个关键设计。强烈建议将库存字段单独拆表而不是放在seckill_goods里。原因是为了减少更新热点。当千万请求都来更新同一行数据的同一个字段库存时InnoDB 的行锁竞争会异常激烈。拆表后这张表可以设计得非常简单goods_id,stock甚至可以使用更优的存储引擎或优化手段。库存预热的实现 在秒杀活动开始前通过一个管理任务或手动触发接口将seckill_stock表中的库存数据加载到 Redis 中。// 伪代码示例库存预热服务 Service public class StockWarmUpService { Autowired private SeckillStockMapper stockMapper; Autowired private RedisTemplateString, Object redisTemplate; public void warmUpStock(Long goodsId) { SeckillStock stock stockMapper.selectByGoodsId(goodsId); if (stock ! null stock.getStock() 0) { String redisKey seckill:stock: goodsId; // 使用 String 或 Hash 类型存储库存 redisTemplate.opsForValue().set(redisKey, stock.getStock()); // 也可以使用更结构化的 Hash存储更多信息 } } }3.2 秒杀核心流程与原子性操作用户点击秒杀后端接口的逻辑链路是重中之重必须保证高效和原子性。参数校验与资格检查校验活动时间、用户登录状态。查询 Redis 中是否已有该用户的“已参与”标记防止同一用户多次抢购。内存库存预扣减关键步骤这是拦截大部分无效请求的关键。使用 Redis 的decr或lua脚本实现原子性扣减。// 使用 Lua 脚本保证原子性查询库存并扣减 String luaScript local stock redis.call(get, KEYS[1]); if stock and tonumber(stock) 0 then redis.call(decr, KEYS[1]); return 1; else return 0; end; DefaultRedisScriptLong script new DefaultRedisScript(luaScript, Long.class); Long result redisTemplate.execute(script, Collections.singletonList(stockKey)); if (result 0) { return Result.error(库存不足); }为什么用 Lua 脚本因为get和decr是两个操作在超高并发下如果不用 Lua 保证其原子性可能会出现“超卖”库存减为负数。Lua 脚本在 Redis 中执行是单线程原子性的。生成临时订单令牌预扣减成功后生成一个临时、有时效性的令牌Token返回给前端。这个令牌代表了用户获得了购买资格但订单尚未真正创建。异步创建订单前端凭令牌调用创建订单接口。该接口首先验证令牌有效性然后将订单信息用户ID、商品ID、令牌作为消息发送到消息队列如 RabbitMQ并立即返回“抢购成功正在生成订单”的结果给用户。订单服务消费独立的订单服务消费者从 MQ 中取出消息进行最终的数据库操作在一个数据库事务中校验库存二次校验防止极端情况、扣减数据库真实库存、生成订单记录、更新用户购买标记到 Redis。这一步即使慢一些用户也无感知。3.3 数据一致性挑战与应对这是秒杀系统最棘手的问题之一缓存Redis中的库存和数据库MySQL中的库存如何保持一致这个项目采用的是“缓存预扣减 异步同步”的最终一致性方案强一致性牺牲性能如果要求实时强一致每次操作都要同时写缓存和数据库并引入分布式锁性能会急剧下降不适合秒杀。最终一致性可接受在秒杀场景下允许极短时间异步处理期间的数据不一致。因为我们通过 Lua 脚本保证了 Redis 内扣减的原子性不会超卖。数据库的扣减是最终保障如果数据库库存不足理论上在 Redis 防护下不应发生会导致异步创建订单失败系统可以通过补偿机制如取消 Redis 预扣减、通知用户来处理这种情况概率极低。对于用户查询“我的订单”可能有一小段时间显示“处理中”这是可以接受的体验。实操心得不要试图在秒杀场景下追求绝对的实时强一致性。接受秒级内的最终一致性是换取系统高性能和高可用的必要权衡。关键是要有完善的监控和补偿告警机制能及时发现和处理异步任务失败的情况。4. 关键技术与优化细节实录4.1 Mybatis 操作优化与防坑指南在秒杀这种高频数据库操作场景下Mybatis 的细微使用不当都可能被放大。#{} 与 ${} 的正确选择这是 Mybatis 面试必考题在秒杀中尤为重要。#{}是预编译参数占位符能有效防止 SQL 注入传入参数会当作字符串处理自动加引号。在绝大多数情况尤其是 WHERE 条件中必须使用#{}。${}是字符串替换直接将参数拼接到 SQL 语句中。存在 SQL 注入风险禁止在用户输入参数中使用。它的适用场景是动态传入表名、列名等非值参数。!-- 安全做法 -- select idselectForUpdate resultTypeSeckillStock SELECT * FROM seckill_stock WHERE goods_id #{goodsId} FOR UPDATE /select !-- 特殊场景动态排序字段需确保字段名安全 -- select idselectOrders resultTypeOrder SELECT * FROM order_info if testorderBy ! null ORDER BY ${orderBy} !-- 假设orderBy是内部传入的‘create_time’等安全字符串 -- /if /select悲观锁与乐观锁的选择悲观锁SELECT ... FOR UPDATE在查询库存时直接加行锁。这种方式简单粗暴能保证强一致性但在超高并发下大量事务排队等锁会导致数据库连接迅速耗尽不推荐在秒杀高峰使用。乐观锁在库存表中增加一个版本号字段version。更新时带上查询时的版本号。UPDATE seckill_stock SET stock stock - 1, version version 1 WHERE goods_id #{goodsId} AND version #{oldVersion} AND stock 0;如果更新影响行数为0说明版本号不对或库存已无更新失败。这种方式并发度高但失败率也高大量请求竞争同一行。在本项目的“缓存预扣减”架构下数据库层的并发压力已经很小可以根据情况选择。如果使用建议结合重试机制。4.2 MySQL 性能优化配置数据库是最后的堡垒它的配置至关重要。连接池配置使用 HikariCP 或 Druid。合理设置maximumPoolSize最大连接数不是越大越好需要根据数据库服务器配置和应用服务器数量估算。设置合理的connectionTimeout和idleTimeout。事务隔离级别通常使用默认的REPEATABLE_READ即可。在扣减库存的场景下要避免使用SERIALIZABLE性能太差。SQL 优化索引seckill_stock表的goods_id必须为主键或唯一索引。订单表的user_id、goods_id、create_time上应考虑建立复合索引加速查询。避免全表扫描所有查询都必须走索引。精简事务尽快提交事务释放锁资源。将一些非核心操作如写日志移到事务外。服务器参数根据实际情况调整innodb_buffer_pool_size设置为可用物理内存的 50%-70%这是 InnoDB 最重要的缓存。max_connections调大以支持更多应用连接但也要考虑服务器负载。innodb_flush_log_at_trx_commit对于秒杀这种可以容忍极短时间数据丢失的场景可以设置为2每秒刷盘能大幅提升写入性能。但需要权衡数据安全性。4.3 缓存与消息队列的深度使用Redis 数据结构选择库存计数使用String类型的incr/decr或Hash字段。用户秒杀标记使用Set或String加过期时间。Set可以方便地查询某个用户是否在集合中。商品详情使用Hash存储商品对象或者用String存储序列化后的 JSON。消息队列的可靠性保证生产者确认Publisher Confirm确保消息成功发送到 MQ Broker。消息持久化将消息和队列都设置为持久化防止 Broker 重启导致消息丢失。消费者确认Consumer Ack设置为手动确认Manual Ack只有在业务处理成功订单创建成功后才向 Broker 返回 ACK。如果处理失败或消费者宕机消息会重新投递。// RabbitMQ 消费者示例 RabbitListener(queues order.create.queue) public void handleOrderCreate(OrderMessage message, Channel channel, Header(AmqpHeaders.DELIVERY_TAG) long tag) { try { // 1. 处理订单创建业务逻辑 orderService.createOrder(message); // 2. 业务成功手动确认 channel.basicAck(tag, false); } catch (Exception e) { // 3. 业务失败根据策略决定是重试还是放入死信队列 channel.basicNack(tag, false, true); // 重新放回队列 } }5. 部署、压测与常见问题排查5.1 系统部署架构建议对于一个准备上线的秒杀系统单机部署是绝对不行的。一个最小化的高可用部署架构应该包括无状态应用层将 SpringBoot 应用部署在多台服务器上前面通过 Nginx 做负载均衡。应用本身不存储会话状态Session用户状态通过 Redis 集中管理。缓存与队列集群Redis 使用主从复制哨兵Sentinel模式或者直接使用 Redis Cluster保证高可用。RabbitMQ 采用镜像队列模式防止队列节点宕机消息丢失。数据库高可用MySQL 采用主从复制Master-Slave读写分离。秒杀写操作走主库读操作如商品详情查询可以走从库。更进一步的可以考虑分库分表但在这个量级的秒杀 demo 中单库优化到位通常可以支撑。5.2 全链路压测实战压测是检验秒杀系统设计的唯一标准。可以使用 JMeter 或阿里云的 PTS 等工具。压测目标找出系统瓶颈是应用 CPU、数据库 IO、还是网络带宽评估系统最大承载 QPS每秒查询率验证限流、降级策略是否生效。压测场景设计库存查询接口模拟用户不断刷新页面这是读请求压力主要在 Redis。秒杀接口模拟用户点击抢购这是写请求压力会从应用层、Redis 层最终传递到数据库和 MQ。混合场景按一定比例混合读写请求模拟真实流量。关键监控指标应用层CPU 使用率、内存使用率、GC 情况、接口响应时间TP99, TP999、错误率。Redis连接数、内存使用率、QPS、命令耗时。MySQLCPU 使用率、IOPS、连接数、慢查询日志、InnoDB 行锁等待。MQ消息堆积数、生产/消费速率。5.3 典型问题排查手册在实际开发和压测中你肯定会遇到下面这些问题问题现象可能原因排查思路与解决方案超卖库存减为负数1. Redis 库存扣减非原子性。2. 数据库更新未加条件判断stock 0。3. 缓存与数据库同步延迟期间有请求绕过缓存直接访问数据库。1.必须使用 Lua 脚本保证 Redis 操作的原子性。2. 数据库更新 SQL 必须加上WHERE stock 0。3. 确保所有库存查询和扣减入口都先走缓存。接口响应慢最终超时1. 应用服务器线程池打满。2. 数据库慢查询或锁等待。3. Redis 连接池不足或操作大 Key。4. 未做限流流量超出系统处理能力。1. 监控线程池状态调整大小。2. 分析 MySQL 慢日志优化 SQL 和索引。3. 检查 Redisslowlog避免使用keys *等命令拆分大 Key。4.实施限流并在网关/应用层快速失败返回。消息队列严重堆积1. 订单消费者处理能力不足如数据库写入慢。2. 消费者服务宕机。3. 消息消费失败不断重试。1. 增加消费者实例数量。2. 优化消费者业务逻辑提升处理速度如批量插入。3. 检查消费者日志修复业务 Bug。对于持续失败的消息应转入死信队列进行人工干预。Redis 连接超时或内存溢出1. 连接池配置过小。2. 存在内存泄漏或未设置过期时间的 Key。3. Redis 实例规格不足。1. 根据并发量调大连接池参数。2.务必为所有缓存 Key 设置合理的 TTL。使用info memory命令分析内存使用情况。3. 升级 Redis 规格或使用 Cluster 分片。“我明明抢到了订单却没生成”1. 异步创建订单消息丢失。2. 消费者处理消息失败且未正确重试。3. 前端显示“成功”是基于令牌生成但后端异步处理最终失败。1. 确保消息队列开启了持久化和生产者确认。2. 完善消费者的异常处理和重试机制并记录详细日志。3. 提供订单查询接口并设计补偿流程如异步任务失败后通知用户并恢复其库存资格。最后一点个人体会构建一个秒杀系统更像是在做一道“约束优化”题。在资源有限服务器、数据库、需求严苛高并发、一致性的条件下寻找最优解。没有银弹所有的技术选型和架构设计都是权衡的结果。这个源码项目给出了一个经过验证的、可行的方案。你可以把它作为一个起点根据自己业务的具体情况比如流量有多大、商品有多热门、团队技术栈如何进行改造和优化。比如引入更精细化的限流降级规则、用 Redis Cluster 替代哨兵模式、或者探索 TiKV 这样的 NewSQL 数据库。多动手部署、压测、观察、调整这个过程本身就是最好的学习。本文还有配套的精品资源点击获取 SpringBoot秒杀系统架构实战：高并发场景下的分层削峰与数据一致性设计
简介高并发系统设计是后端开发的核心挑战之一其核心原理在于通过架构手段应对瞬时流量洪峰保障系统稳定。技术价值体现在通过分层设计、缓存策略和异步处理在有限的资源下最大化系统吞吐量与可用性。典型的应用场景包括电商秒杀、票务抢购等瞬时高并发业务。本文以SpringBoot和MySQL为基础技术栈深入剖析了如何利用Redis缓存进行库存预热和原子扣减并结合消息队列实现异步订单处理从而有效解决超卖问题平滑数据库压力构建一个高性能、高可用的秒杀系统。1. 项目概述与核心价值最近在整理硬盘翻出来一个几年前参与过的商城秒杀系统源码包。这个项目在当时算是一个比较典型的“高并发、高性能”实战案例麻雀虽小五脏俱全。今天正好借这个机会把这个基于 SpringBoot Mybatis MySQL 的秒杀系统从架构设计到代码实现的里里外外给大家掰开揉碎了讲一讲。无论你是想学习如何应对瞬时流量洪峰还是想了解一个完整电商后端核心模块的构建这个项目都能给你提供不少直接的参考。秒杀说白了就是在极短的时间内比如几秒钟将少量极具吸引力的商品比如特价手机、限量球鞋卖给海量的用户。这听起来简单但技术挑战巨大瞬时超高并发、有限的库存、绝对的公平性、以及防止系统被压垮。这个源码项目就是围绕这些核心挑战展开的。它没有用到特别“黑科技”的组件而是基于当时现在依然主流的技术栈通过合理的架构分层、缓存策略、异步处理和数据库优化构建了一个能扛住一定压力、保证核心流程正确的系统。对于想从 CRUD 进阶到高并发系统设计的开发者来说这是一个非常好的练手和学习的样本。2. 系统架构设计与核心思路拆解拿到一个秒杀系统我们首先要思考的不是写代码而是设计。核心思路就一句话将大部分请求拦截在系统上游让尽可能少的请求穿透到数据库。2.1 分层削峰与流量控制一个未经优化的秒杀流程是用户点击“立即抢购” - 请求直达应用服务器 - 应用服务器查询数据库库存 - 扣减库存 - 创建订单。这在万人同时点击的瞬间数据库连接池会被瞬间打满轻则响应缓慢重则直接宕机这就是所谓的“雪崩效应”。这个项目的架构采用了典型的分层削峰策略前端层面按钮防重复提交前端JS控制点击后置灰、倒计时校准避免用户本地时间不准导致提前请求、随机化请求路径增加脚本攻击难度。网关/负载均衡层虽然这个 demo 项目可能没集成但在真实场景中这一层会进行限流如 Nginx 的limit_req模块、恶意 IP 封禁。应用层我们的 SpringBoot 服务这是核心防护阵地。我们采用令牌桶或漏桶算法进行限流确保进入核心业务逻辑的请求速率是可控的。例如使用 Guava 的RateLimiter或集成 Sentinel 组件。缓存层这是扛住瞬时流量的王牌。商品库存信息提前预热到 Redis 中所有的库存查询和预扣减都在内存中进行速度极快。数据库层经过前面几层的过滤到达数据库的写请求最终扣减库存、创建订单已经大大减少。我们通过消息队列异步化和数据库事务优化来平稳处理这些请求。注意限流不是为了拒绝用户而是为了保护系统。被限流的请求应该获得友好的提示如“活动太火爆请稍后再试”而不是一个冷冰冰的 500 错误。2.2 技术栈选型背后的考量SpringBoot作为微服务时代的“快速启动器”它简化了配置让我们能快速搭建一个可独立运行、内嵌 Tomcat 的 Web 应用。它的自动配置、Starter 依赖和 Actuator 监控端点对于需要快速迭代和部署的秒杀场景非常友好。Mybatis相比 JPA 的全自动化Mybatis 提供了更灵活的 SQL 掌控能力。在秒杀这种对数据库操作性能极其敏感的场景我们往往需要编写高度优化的 SQL甚至使用一些数据库特定的语法。Mybatis 的 XML 配置或注解方式能让我们清晰地管理和优化这些 SQL。MySQL关系型数据库的绝对主流事务保证ACID是秒杀公平性和数据一致性的基石。虽然最终会引入缓存但库存和订单的“唯一真理源”必须落在数据库上。中间件Redis RabbitMQ/RocketMQRedis扮演缓存和分布式计数器的角色。存储秒杀库存、用户秒杀资格标记防重复购买、以及热点数据。其单线程内存操作模型在高并发读场景下性能卓越。消息队列MQ扮演异步处理器和流量缓冲区的角色。用户秒杀成功的请求并不直接同步创建订单和扣库而是发送一个消息到 MQ。由后台的订单服务消费者异步处理。这能将耗时操作写库、发短信与用户请求响应解耦极大缩短前端响应时间并平滑数据库写入压力。这个技术栈组合是在性能、开发效率、可控性和社区成熟度之间取得的一个经典平衡。3. 核心模块解析与实现要点让我们深入到代码内部看看几个最关键的部分是如何实现的。3.1 商品与库存模型设计库存是秒杀的核心。在数据库里我们至少需要两张表seckill_goods(秒杀商品表)包含商品ID、原价、秒杀价、初始库存、开始时间、结束时间等。seckill_stock(秒杀库存表)这是一个关键设计。强烈建议将库存字段单独拆表而不是放在seckill_goods里。原因是为了减少更新热点。当千万请求都来更新同一行数据的同一个字段库存时InnoDB 的行锁竞争会异常激烈。拆表后这张表可以设计得非常简单goods_id,stock甚至可以使用更优的存储引擎或优化手段。库存预热的实现 在秒杀活动开始前通过一个管理任务或手动触发接口将seckill_stock表中的库存数据加载到 Redis 中。// 伪代码示例库存预热服务 Service public class StockWarmUpService { Autowired private SeckillStockMapper stockMapper; Autowired private RedisTemplateString, Object redisTemplate; public void warmUpStock(Long goodsId) { SeckillStock stock stockMapper.selectByGoodsId(goodsId); if (stock ! null stock.getStock() 0) { String redisKey seckill:stock: goodsId; // 使用 String 或 Hash 类型存储库存 redisTemplate.opsForValue().set(redisKey, stock.getStock()); // 也可以使用更结构化的 Hash存储更多信息 } } }3.2 秒杀核心流程与原子性操作用户点击秒杀后端接口的逻辑链路是重中之重必须保证高效和原子性。参数校验与资格检查校验活动时间、用户登录状态。查询 Redis 中是否已有该用户的“已参与”标记防止同一用户多次抢购。内存库存预扣减关键步骤这是拦截大部分无效请求的关键。使用 Redis 的decr或lua脚本实现原子性扣减。// 使用 Lua 脚本保证原子性查询库存并扣减 String luaScript local stock redis.call(get, KEYS[1]); if stock and tonumber(stock) 0 then redis.call(decr, KEYS[1]); return 1; else return 0; end; DefaultRedisScriptLong script new DefaultRedisScript(luaScript, Long.class); Long result redisTemplate.execute(script, Collections.singletonList(stockKey)); if (result 0) { return Result.error(库存不足); }为什么用 Lua 脚本因为get和decr是两个操作在超高并发下如果不用 Lua 保证其原子性可能会出现“超卖”库存减为负数。Lua 脚本在 Redis 中执行是单线程原子性的。生成临时订单令牌预扣减成功后生成一个临时、有时效性的令牌Token返回给前端。这个令牌代表了用户获得了购买资格但订单尚未真正创建。异步创建订单前端凭令牌调用创建订单接口。该接口首先验证令牌有效性然后将订单信息用户ID、商品ID、令牌作为消息发送到消息队列如 RabbitMQ并立即返回“抢购成功正在生成订单”的结果给用户。订单服务消费独立的订单服务消费者从 MQ 中取出消息进行最终的数据库操作在一个数据库事务中校验库存二次校验防止极端情况、扣减数据库真实库存、生成订单记录、更新用户购买标记到 Redis。这一步即使慢一些用户也无感知。3.3 数据一致性挑战与应对这是秒杀系统最棘手的问题之一缓存Redis中的库存和数据库MySQL中的库存如何保持一致这个项目采用的是“缓存预扣减 异步同步”的最终一致性方案强一致性牺牲性能如果要求实时强一致每次操作都要同时写缓存和数据库并引入分布式锁性能会急剧下降不适合秒杀。最终一致性可接受在秒杀场景下允许极短时间异步处理期间的数据不一致。因为我们通过 Lua 脚本保证了 Redis 内扣减的原子性不会超卖。数据库的扣减是最终保障如果数据库库存不足理论上在 Redis 防护下不应发生会导致异步创建订单失败系统可以通过补偿机制如取消 Redis 预扣减、通知用户来处理这种情况概率极低。对于用户查询“我的订单”可能有一小段时间显示“处理中”这是可以接受的体验。实操心得不要试图在秒杀场景下追求绝对的实时强一致性。接受秒级内的最终一致性是换取系统高性能和高可用的必要权衡。关键是要有完善的监控和补偿告警机制能及时发现和处理异步任务失败的情况。4. 关键技术与优化细节实录4.1 Mybatis 操作优化与防坑指南在秒杀这种高频数据库操作场景下Mybatis 的细微使用不当都可能被放大。#{} 与 ${} 的正确选择这是 Mybatis 面试必考题在秒杀中尤为重要。#{}是预编译参数占位符能有效防止 SQL 注入传入参数会当作字符串处理自动加引号。在绝大多数情况尤其是 WHERE 条件中必须使用#{}。${}是字符串替换直接将参数拼接到 SQL 语句中。存在 SQL 注入风险禁止在用户输入参数中使用。它的适用场景是动态传入表名、列名等非值参数。!-- 安全做法 -- select idselectForUpdate resultTypeSeckillStock SELECT * FROM seckill_stock WHERE goods_id #{goodsId} FOR UPDATE /select !-- 特殊场景动态排序字段需确保字段名安全 -- select idselectOrders resultTypeOrder SELECT * FROM order_info if testorderBy ! null ORDER BY ${orderBy} !-- 假设orderBy是内部传入的‘create_time’等安全字符串 -- /if /select悲观锁与乐观锁的选择悲观锁SELECT ... FOR UPDATE在查询库存时直接加行锁。这种方式简单粗暴能保证强一致性但在超高并发下大量事务排队等锁会导致数据库连接迅速耗尽不推荐在秒杀高峰使用。乐观锁在库存表中增加一个版本号字段version。更新时带上查询时的版本号。UPDATE seckill_stock SET stock stock - 1, version version 1 WHERE goods_id #{goodsId} AND version #{oldVersion} AND stock 0;如果更新影响行数为0说明版本号不对或库存已无更新失败。这种方式并发度高但失败率也高大量请求竞争同一行。在本项目的“缓存预扣减”架构下数据库层的并发压力已经很小可以根据情况选择。如果使用建议结合重试机制。4.2 MySQL 性能优化配置数据库是最后的堡垒它的配置至关重要。连接池配置使用 HikariCP 或 Druid。合理设置maximumPoolSize最大连接数不是越大越好需要根据数据库服务器配置和应用服务器数量估算。设置合理的connectionTimeout和idleTimeout。事务隔离级别通常使用默认的REPEATABLE_READ即可。在扣减库存的场景下要避免使用SERIALIZABLE性能太差。SQL 优化索引seckill_stock表的goods_id必须为主键或唯一索引。订单表的user_id、goods_id、create_time上应考虑建立复合索引加速查询。避免全表扫描所有查询都必须走索引。精简事务尽快提交事务释放锁资源。将一些非核心操作如写日志移到事务外。服务器参数根据实际情况调整innodb_buffer_pool_size设置为可用物理内存的 50%-70%这是 InnoDB 最重要的缓存。max_connections调大以支持更多应用连接但也要考虑服务器负载。innodb_flush_log_at_trx_commit对于秒杀这种可以容忍极短时间数据丢失的场景可以设置为2每秒刷盘能大幅提升写入性能。但需要权衡数据安全性。4.3 缓存与消息队列的深度使用Redis 数据结构选择库存计数使用String类型的incr/decr或Hash字段。用户秒杀标记使用Set或String加过期时间。Set可以方便地查询某个用户是否在集合中。商品详情使用Hash存储商品对象或者用String存储序列化后的 JSON。消息队列的可靠性保证生产者确认Publisher Confirm确保消息成功发送到 MQ Broker。消息持久化将消息和队列都设置为持久化防止 Broker 重启导致消息丢失。消费者确认Consumer Ack设置为手动确认Manual Ack只有在业务处理成功订单创建成功后才向 Broker 返回 ACK。如果处理失败或消费者宕机消息会重新投递。// RabbitMQ 消费者示例 RabbitListener(queues order.create.queue) public void handleOrderCreate(OrderMessage message, Channel channel, Header(AmqpHeaders.DELIVERY_TAG) long tag) { try { // 1. 处理订单创建业务逻辑 orderService.createOrder(message); // 2. 业务成功手动确认 channel.basicAck(tag, false); } catch (Exception e) { // 3. 业务失败根据策略决定是重试还是放入死信队列 channel.basicNack(tag, false, true); // 重新放回队列 } }5. 部署、压测与常见问题排查5.1 系统部署架构建议对于一个准备上线的秒杀系统单机部署是绝对不行的。一个最小化的高可用部署架构应该包括无状态应用层将 SpringBoot 应用部署在多台服务器上前面通过 Nginx 做负载均衡。应用本身不存储会话状态Session用户状态通过 Redis 集中管理。缓存与队列集群Redis 使用主从复制哨兵Sentinel模式或者直接使用 Redis Cluster保证高可用。RabbitMQ 采用镜像队列模式防止队列节点宕机消息丢失。数据库高可用MySQL 采用主从复制Master-Slave读写分离。秒杀写操作走主库读操作如商品详情查询可以走从库。更进一步的可以考虑分库分表但在这个量级的秒杀 demo 中单库优化到位通常可以支撑。5.2 全链路压测实战压测是检验秒杀系统设计的唯一标准。可以使用 JMeter 或阿里云的 PTS 等工具。压测目标找出系统瓶颈是应用 CPU、数据库 IO、还是网络带宽评估系统最大承载 QPS每秒查询率验证限流、降级策略是否生效。压测场景设计库存查询接口模拟用户不断刷新页面这是读请求压力主要在 Redis。秒杀接口模拟用户点击抢购这是写请求压力会从应用层、Redis 层最终传递到数据库和 MQ。混合场景按一定比例混合读写请求模拟真实流量。关键监控指标应用层CPU 使用率、内存使用率、GC 情况、接口响应时间TP99, TP999、错误率。Redis连接数、内存使用率、QPS、命令耗时。MySQLCPU 使用率、IOPS、连接数、慢查询日志、InnoDB 行锁等待。MQ消息堆积数、生产/消费速率。5.3 典型问题排查手册在实际开发和压测中你肯定会遇到下面这些问题问题现象可能原因排查思路与解决方案超卖库存减为负数1. Redis 库存扣减非原子性。2. 数据库更新未加条件判断stock 0。3. 缓存与数据库同步延迟期间有请求绕过缓存直接访问数据库。1.必须使用 Lua 脚本保证 Redis 操作的原子性。2. 数据库更新 SQL 必须加上WHERE stock 0。3. 确保所有库存查询和扣减入口都先走缓存。接口响应慢最终超时1. 应用服务器线程池打满。2. 数据库慢查询或锁等待。3. Redis 连接池不足或操作大 Key。4. 未做限流流量超出系统处理能力。1. 监控线程池状态调整大小。2. 分析 MySQL 慢日志优化 SQL 和索引。3. 检查 Redisslowlog避免使用keys *等命令拆分大 Key。4.实施限流并在网关/应用层快速失败返回。消息队列严重堆积1. 订单消费者处理能力不足如数据库写入慢。2. 消费者服务宕机。3. 消息消费失败不断重试。1. 增加消费者实例数量。2. 优化消费者业务逻辑提升处理速度如批量插入。3. 检查消费者日志修复业务 Bug。对于持续失败的消息应转入死信队列进行人工干预。Redis 连接超时或内存溢出1. 连接池配置过小。2. 存在内存泄漏或未设置过期时间的 Key。3. Redis 实例规格不足。1. 根据并发量调大连接池参数。2.务必为所有缓存 Key 设置合理的 TTL。使用info memory命令分析内存使用情况。3. 升级 Redis 规格或使用 Cluster 分片。“我明明抢到了订单却没生成”1. 异步创建订单消息丢失。2. 消费者处理消息失败且未正确重试。3. 前端显示“成功”是基于令牌生成但后端异步处理最终失败。1. 确保消息队列开启了持久化和生产者确认。2. 完善消费者的异常处理和重试机制并记录详细日志。3. 提供订单查询接口并设计补偿流程如异步任务失败后通知用户并恢复其库存资格。最后一点个人体会构建一个秒杀系统更像是在做一道“约束优化”题。在资源有限服务器、数据库、需求严苛高并发、一致性的条件下寻找最优解。没有银弹所有的技术选型和架构设计都是权衡的结果。这个源码项目给出了一个经过验证的、可行的方案。你可以把它作为一个起点根据自己业务的具体情况比如流量有多大、商品有多热门、团队技术栈如何进行改造和优化。比如引入更精细化的限流降级规则、用 Redis Cluster 替代哨兵模式、或者探索 TiKV 这样的 NewSQL 数据库。多动手部署、压测、观察、调整这个过程本身就是最好的学习。本文还有配套的精品资源点击获取