摘要：在当今数字化浪潮中，电商促销活动频繁，抢券热潮此起彼伏。对于互联网软件开发人员而言，构建一个简单高效的抢券系统，既能满足业务需求，又能提升用户体验，无疑是一项极具价值的挑战。今天，咱们就深入探讨一下如何打造这样一个系统。
在当今数字化浪潮中，电商促销活动频繁，抢券热潮此起彼伏。对于互联网软件开发人员而言，构建一个简单高效的抢券系统，既能满足业务需求，又能提升用户体验，无疑是一项极具价值的挑战。今天，咱们就深入探讨一下如何打造这样一个系统。
（一）抢券业务场景分析
抢券场景与秒杀业务类似，具有鲜明特征。其并发量极高，在活动开启瞬间，可能每秒涌入几万甚至几十万请求。以双 11 大促的优惠券抢购为例，大量用户同时点击抢券按钮，服务器瞬间面临巨大压力。库存方面，优惠券数量固定有限，这就要求系统精准控制发放数量，避免超发。而且，每次抢券请求都可能涉及修改库存、生成订单等写操作，数据一致性要求严苛，绝对不能出现发出超过库存数量券的情况。
（二）抢券系统的核心挑战
高并发：瞬间大量请求涌入，数据库或应用服务器难以招架。想象一下，服务器就像一个繁忙的客服中心，同时接到海量电话，处理能力面临严峻考验。
数据一致性：多线程同时读取库存时，可能因并发冲突导致超卖。比如两个用户同时读取到库存为 1，都判断可以抢券，最终造成超卖。
性能瓶颈：数据库写入能力存在上限，每秒事务处理数（TPS）和每秒查询请求数（QPS）受限。传统数据库在高并发写操作下，性能容易急剧下降。
可扩展性：单机处理能力有限，随着业务增长，必须支持横向扩展，增加服务器数量来提升处理能力。
系统优化的首要任务是理解性能指标。
（一）QPS：每秒查询请求数（Queries Per Second）
这一指标常用于衡量接口的处理能力，涵盖读请求，像查询用户状态、查库存等操作。例如，一台服务器在 10 秒内处理了 20,000 个接口请求，其 QPS 即为 2000。静态资源（如图片、JS）常由 CDN 分担流量，QPS 可高达 10,000 以上。但动态接口，尤其是涉及数据库写入的 “扣库存” 接口，QPS 会显著降低。
（二）TPS：每秒事务处理数（Transactions Per Second）
该指标更侧重于数据库或交易系统，关注 “写操作” 处理能力，如订单生成、扣库存等。一般情况下，TPS 小于 QPS，因为写操作成本更高，需保障事务完整性和数据持久化。
（一）超卖现象回顾
假设库存仅有 1 张优惠券，此时两个用户同时发起抢券请求。系统读取库存时，两人获取到的库存都为 1，都判断可以成功抢券，最终都进行了扣减库存操作，结果导致超卖 1 张券。
（二）为什么会超卖？
根本原因在于多个请求并发读取库存时，读取到的都是相同旧值。由于并发操作，在一个请求还未完成库存更新时，其他请求又读取了旧的库存数据，造成多个请求都认为库存充足，进而并发写入，引发超卖。这是典型的并发冲突问题。
（一）使用 Java synchronized 同步锁
代码实现如下：
public synchronized void 抢券 { if (库存 > 0) { 库存--; // 下单逻辑 }}优点：实现简单，适合单机测试场景，在 JVM 层加锁，能保证线程安全。
缺点：仅在单个 JVM 内生效，若系统进行多实例部署，无法共享锁。而且是串行处理请求，吞吐量极低，根本无法适应高并发场景。
（二）数据库悲观锁：SELECT... FOR UPDATE
操作流程如下：
START TRANSACTION;SELECT * FROM coupon WHERE id = 1 FOR UPDATE;-- 判断库存 > 0UPDATE coupon SET stock = stock - 1 WHERE id = 1;COMMIT;优点：能确保事务强一致性，适用于对数据一致性要求极高的金融、电商核心业务。
缺点：会锁表或锁行，在高并发情况下，阻塞现象严重，性能极差，不适合 QPS 大于 100 的场景。
（三）数据库乐观锁（CAS 机制）
表结构需新增 version 字段，每次更新时加上版本号条件，如：
UPDATE coupon SET stock = stock - 1, version = version + 1 WHERE id = 1 AND version = 当前版本号;优点：无需加锁，提升了并发性能，支持多线程并发执行。
缺点：随着并发量升高，更新成功率降低，需要添加重试逻辑。而且编码复杂，需额外维护字段和控制逻辑。
（四）Redis 分布式锁控制并发访问
使用 SETNX 或 Redisson 实现分布式锁机制，示例代码如下：
// 获取锁Boolean success = redis.setIfAbsent("lock_key", "UUID", 5 秒过期);if (success) { try { // 查询库存、扣减逻辑 } finally { // 释放锁 redis.del("lock_key"); }}优点：支持分布式部署，可精准控制访问。
缺点：存在性能瓶颈，每个请求都需访问 Redis 执行 SETNX 操作。同时，还面临死锁、锁丢失等问题，需设置过期时间和唯一标识来解决。
Redis 提供天然的原子命令，如 DECR ，原理是 Redis 为单线程，所有命令天然串行执行，保证操作原子性。
使用方式如下：
DECR coupon_stock优势显著：
性能极高：单线程执行命令，无需加锁，处理百万 QPS 不在话下。
支持并发安全：自身具备原子性，无需额外加锁。
网络请求少：无需读 - 判断 - 写三步操作，仅需一次写操作。
易于扩展：可搭配 Lua 脚本，进一步实现复杂逻辑判断。
典型逻辑是将库存预热到 Redis 中，设置 key 为 coupon:stock:123 。抢券请求使用 DECR 扣减库存，若 DECR 结果大于等于 0，表示抢券成功，可异步入库。
抢券系统遵循 “缓存优先 + 异步解耦 + 原子操作” 设计原则，核心技术组件如下：
（一）Redis 缓存
用于预热活动数据、缓存库存以及记录抢券结果。提前将活动信息和库存数据存入 Redis ，可大幅减少数据库压力。
（二）Lua 脚本
保证库存扣减和记录写入等操作的原子性，避免并发不一致和超卖问题。将一系列相关操作封装在 Lua 脚本中，通过 Redis 的 EVAL 命令执行，确保脚本整体原子性。
（三）异步队列
记录抢券结果，用于后续与 MySQL 同步。在高并发下，将数据先存入异步队列，可有效削峰，解耦落库压力。
（四）线程池
并发处理多个活动的抢券结果同步任务，提升写入吞吐量。合理配置线程池参数，可优化任务处理效率。
（五）定时任务
定期更新活动状态、预热数据，确保系统数据实时准确。
系统数据流结构如下：
用户请求 ↓前端调用抢券接口 ↓执行 Lua 脚本（Redis） ↓写入成功列表 & 同步队列（Redis） ↓定时任务拉取数据 → 写入 MySQL为避免高并发下数据库压力过大，系统采用定时预热机制。将近 1 个月内即将开始和正在进行的优惠券活动信息写入 Redis ，结构如下：
key: ACTIVITY:LISTvalue: 活动信息列表（JSON 串）缓存更新依靠定时任务和状态判断逻辑自动完成。借助 activity.getDistributeStartTime 与 DateUtils.now 动态判断实时状态，确保展示信息准确无误。
库存数据缓存采用 Hash 结构：
Hash 结构：COUPON:RESOURCE:STOCK:{活动 ID % 10}Field：活动 IDValue：库存数抢券过程涉及多项 Redis 操作，需保证整体原子性。使用 Lua 脚本完成抢券流程，其功能如下：
判断用户是否已抢过券。判断库存是否充足。扣减库存。写入抢券成功列表（防止重复抢券）。写入同步队列（待写入 MySQL ）。执行示意如下：
-- 示例伪代码if has 抢过 then return -1if 库存不足 then return -2写入抢券成功列表库存 - 1写入同步队列return 活动 ID所有逻辑通过 EVAL 命令执行，Redis 保证整个 Lua 脚本原子性。
POST /market/consumer/coupon/seize参数为活动 ID ，通过 UserContext 获取当前用户。
关键逻辑流程如下：
Redis 仅暂存抢券结果，为确保数据落库，设计多线程同步机制。
在 Redis 中维护 Hash 同步队列：
key: QUEUE:COUPON:SEIZE:SYNC:{活动 ID % 10}field: 用户 IDvalue: 活动 ID使用线程池从 10 个同步队列中并发扫描（scan）数据。成功写入 MySQL 后删除 Redis 记录。线程池配置如下：
new ThreadPoolExecutor( corePoolSize = 1, maxPoolSize = 10, keepAliveTime = 120, unit = SECONDS, workQueue = new SynchronousQueue, handler = new DiscardPolicy)定时任务调度每分钟执行一次，实现持续低延迟同步。
针对高并发挑战，系统设计中融入多项性能优化措施：
热点数据预热：提前将活动数据和库存存入 Redis ，避免缓存穿透，减少数据库压力。Redis 原子操作替代数据库锁：利用 Redis 原子命令，提升并发性能。Lua 脚本批量操作：保证操作原子性，防止超卖。异步队列削峰：解耦落库压力，提升系统稳定性。多线程处理同步：提高写入吞吐量。此外，为实现系统弹性伸缩与安全防护，可配合限流（如 Sentinel）、验证码、灰度发布等机制进一步增强系统性能和安全性。
构建一个简单高效的抢券系统并非易事，需要综合考虑业务特点、技术选型、性能优化等多方面因素。通过合理运用 Redis 、Lua 脚本、异步队列等技术，精心设计系统架构，能够打造出一个稳定、高效，满足高并发抢券需求的系统，为用户带来流畅的抢券体验，助力业务蓬勃发展。各位互联网软件开发的小伙伴们，行动起来，将这些技术运用到实际项目中吧！
来源：从程序员到架构师
