“真神复活”这类限时运营活动用户端看到的往往只有一个“领取”按钮后端却要处理资格校验、幂等控制、库存扣减、发放记录和对账核对等一系列问题。按钮点击一次看似简单生产环境里重复发放、超发、活动结束后仍可领取等事故绝大多数都出在这条链路上。本文以这类“可直接领取”的运营活动为背景设计一个最小可复用的奖励领取系统覆盖数据表建模、服务端接口流程、并发防超发、本地验证和对账排查。读者如果是后端开发、游戏服务端研发或电商活动研发可以直接按这套思路落地到自己的项目里再根据实际活动规则调整校验逻辑。整篇文章不是只讲理论核心是四个动作先拆清领取系统要解决什么问题再用建表 SQL 把活动、资格、库存、流水四类数据落库接着实现一个带幂等和并发控制的领取接口最后用并发请求和 SQL 验证结果并且给出排查路径。1. 先拆解“真神复活”活动里“领取”按钮背后的子系统链路1.1 活动领取场景并不只有“点击领取”这一种运营活动叫“真神复活”但技术实现不能只针对这一个活动。开发时要把活动抽象成通用能力否则下一个活动上线又要从头写一遍。常规活动场景至少有以下几类场景说明常见例子无条件领取活动时间内登录即可领取无需额外条件登录礼包、回归奖励资格名单领取运营提前导入白名单用户进入页面才能领内测资格、定向邀请奖励条件领取完成指定任务或达到关卡后解锁通关第 5 章后领取复活券限量领取活动总份数固定先到先得限量称号、限量和实体周边限额领取每个用户限制领取次数可叠加时间窗口每人每天领取一次不同场景对后端的要求完全不一样。无条件领取重点防重复名单领取重点校验资格限量领取重点防超发限额领取重点处理周期窗口。实际设计领取系统时不能只为一个活动写死逻辑而是把“领取资格、领取次数、库存、发放记录”拆成独立模块。1.2 三个边界条件最容易出事故任何“可直接领取”的活动本质上都要回答三个边界问题时间边界、次数边界、库存边界。时间边界是最容易踩坑的一层。活动页显示“活动进行中”但用户请求到达服务器时可能刚好过了结束时间。这种情况不能只靠前端按钮控制服务端必须用服务器的当前时间判断活动开始和结束时间。核心原则是以服务端时间为主前端时间只做展示。次数边界要比“是否领过”多一点。只是判断用户有没有领取记录还不够因为有些活动是每人每天可领一次有些是活动期间总共可领三次。领取记录表要能支持按时间窗口统计不能只靠一张状态位判断。库存边界在限量活动里是硬要求。用户看到页面有剩余库存点击领取时可能已经被别人抢完。这要求库存扣减必须是一个原子操作不能先用 select 查出剩余数量再在 Java 代码里判断是否大于 0然后再 update。因为并发请求会在“查出数量”和“更新数量”之间同时读到同一个剩余值。注意领取系统上线前先把这三个边界问题写在需求评审里。如果产品文档没有明确说明活动结束后如何处理进行中的请求、用户重复点击如何返回、库存扣完时是否允许排队后端必须主动找产品确认。2. 用四张表把活动、用户、库存、流水建模领取系统的数据模型可以拆成四张表活动配置表、用户资格表、用户领取记录表、活动库存表。核心原则是配置与库存分离资格与记录分离。2.1 活动配置表只描述活动是什么活动配置表存放活动编码、名称、时间范围、状态、每人限领次数和库存总量。设计这类表时要注意不要直接在这个表上扣库存否则一次库存变动就会锁住整条活动配置行影响活动信息的读取。CREATE TABLE activity ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL COMMENT 活动编码建议业务可读, activity_name VARCHAR(128) NOT NULL COMMENT 活动名称, start_time DATETIME NOT NULL COMMENT 活动开始时间, end_time DATETIME NOT NULL COMMENT 活动结束时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1进行中 2暂停 3结束, limit_per_user INT NOT NULL DEFAULT 1 COMMENT 每个用户限领次数, need_qualification TINYINT NOT NULL DEFAULT 0 COMMENT 是否需要资格名单, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_activity_code (activity_code) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;活动编码不要用自增主键暴露给业务入口建议使用固定字符串比如zsff_2025_anniversary这样日志里查问题非常直观。活动状态也要区分草稿、进行中、暂停、结束不能只靠时间字段判断否则活动临时下线时没有可操作的开关。2.2 用户资格表名单型活动必须单独建表无条件和名单型活动最大的区别是前者所有用户都可以领后者只有计算机里能查到的用户才能领。用户资格表就是用于存放这份白名单。CREATE TABLE activity_qualification ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未领取 1已领取, source VARCHAR(32) NOT NULL DEFAULT MANUAL COMMENT 资格来源, ext_info VARCHAR(1024) COMMENT 扩展信息如资格等级、批次号, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_qualification (activity_code, user_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;资格表加唯一索引(activity_code, user_id)是防止运营在导入名单时重复写入同时也是后续校验资格时能走索引查询的基础。这里要区分“资格是否使用”和“领取记录是否存在”资格表只关注用户有没有资格、资格有没有被消耗领取记录的明细则放在下一张表。2.3 用户领取记录表记录每次领取的幂等结果用户领取记录表是整个系统的核心表。它记录每一次领取尝试的结果而不仅仅是“谁领了奖励”。这张表同时承担幂等键存储和领取流水审计两个职责。CREATE TABLE user_receive_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL COMMENT 幂等键一次点击对应一个ID, activity_code VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, reward_code VARCHAR(64) NOT NULL COMMENT 奖励编码, receive_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0发放中 1成功 2失败 3已回滚, fail_reason VARCHAR(512) COMMENT 失败原因, UNIQUE KEY uk_biz_id (biz_id), KEY idx_user_activity (activity_code, user_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;biz_id是幂等键由前端在用户点击按钮时生成或者由后端在接收请求时生成。同一个用户连续快速点击如果前端每次都生成一个新 UUID那服务端无法识别这是同一次点击所以必须让“一次点击”在整个重试周期内使用同一个biz_id。user_receive_record表的唯一索引uk_biz_id是防重复发放的最后一道兜底。状态字段用“0 发放中、1 成功、2 失败、3 已回滚”而不是简单用一个布尔值。原因是发放奖励可能是异步过程接口先返回成功但后台发货回调失败时还要能更新状态便于对账。2.4 活动库存表独立表承担扣减操作限量活动需要单独一张库存表。库存表中只有活动编码、剩余数量和版本号三列。CREATE TABLE activity_inventory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL, remain_count INT NOT NULL, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_activity (activity_code) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;这张表不关心“一开始总量是多少”总量放在活动配置表里。这里只关心剩余量。扣减时要求原子地将remain_count减 1并且只有剩余量大于 0 才能扣减成功。后续会看到并发防超发的关键就在这条 update 语句上。3. 领取接口核心流程校验、幂等、扣减、发放3.1 接口定义与请求结构领取接口属于写操作建议使用 POST请求体包含活动编码、用户标识、幂等键和渠道信息。一个典型的接口请求结构如下。{ activityCode: zsff_2025, userId: 10001, bizId: click-10001-20250601093012-8f3a, channel: APP }bizId的生成规则可以没有统一格式只要能在一次点击的生命周期内保持一致即可。服务端接收请求后第一个动作就是用这个bizId查领取记录如果已经存在则直接返回成功结果不再执行后续逻辑。3.2 主流程代码实现下面这段代码使用 Spring Boot 的 Service 写法MyBatis 负责数据库访问。它按“幂等检查、活动校验、次数校验、资格校验、库存扣减、记录插入、资格标记”的顺序执行。Service public class ReceiveService { Resource private ReceiveRecordMapper receiveRecordMapper; Resource private ActivityMapper activityMapper; Resource private QualificationMapper qualificationMapper; Resource private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) public ReceiveResult receive(ReceiveRequest request) { // 1. 幂等检查同一个 bizId 只处理一次 ReceiveRecord existing receiveRecordMapper.selectByBizId(request.getBizId()); if (existing ! null) { return ReceiveResult.from(existing); } // 2. 活动规则校验 Activity activity activityMapper.selectByCode(request.getActivityCode()); LocalDateTime now LocalDateTime.now(); if (activity null || activity.getStatus() ! 1 || now.isBefore(activity.getStartTime()) || now.isAfter(activity.getEndTime())) { throw new BusinessException(活动不存在、未开始或已结束); } // 3. 领取次数校验 int receivedCount receiveRecordMapper.countSuccess( request.getUserId(), request.getActivityCode()); if (receivedCount activity.getLimitPerUser()) { throw new BusinessException(已达个人领取上限); } // 4. 资格校验 if (activity.getNeedQualification() 1) { Qualification qualification qualificationMapper.selectByActivityAndUser( request.getActivityCode(), request.getUserId()); if (qualification null) { throw new BusinessException(没有领取资格); } if (qualification.getStatus() 1) { throw new BusinessException(资格已被使用); } } // 5. 库存扣减 int rows inventoryMapper.decrease(request.getActivityCode(), 1); if (rows 0) { throw new BusinessException(活动库存已领完); } // 6. 插入领取记录 ReceiveRecord record new ReceiveRecord(); record.setBizId(request.getBizId()); record.setActivityCode(request.getActivityCode()); record.setUserId(request.getUserId()); record.setRewardCode(activity.getRewardCode()); record.setReceiveTime(now); record.setStatus(1); receiveRecordMapper.insert(record); // 7. 标记资格已使用 if (activity.getNeedQualification() 1) { qualificationMapper.markUsed( request.getActivityCode(), request.getUserId()); } return ReceiveResult.success(record); } }这里要注意两个细节。第一个细节是第 3 步的countSuccess统计的是状态为成功的记录而不是所有记录。如果发放失败重试失败记录不应该占用用户的领取次数。第二个细节是第 5 步库存扣减必须使用下面这种原子 SQL而不是先查询再判断UPDATE activity_inventory SET remain_count remain_count - 1, version version 1 WHERE activity_code #{activityCode} AND remain_count 0;这条 SQL 依赖数据库行锁保证原子性。只要剩余量大于 0并且更新影响行数为 1就表示扣减成功。并发场景下多个请求同时执行这条语句时只有一条可以成功把库存从 1 减到 0其他请求都会命中remain_count 0条件失败。3.3 发放奖励放在事务里还是事务外上面的示例把插入领取记录和库存扣减放在同一个本地事务里。但“发放奖励”这个动作在实际项目中可能是调用内部钱包服务、发放游戏道具、发送优惠券甚至是调用第三方物流发货。把这类外部调用放在事务里会让数据库事务持续时间变长也容易造成事务回滚后外部服务却已经发货成功的“幽灵发放”问题。推荐做法是区分两个阶段第一阶段本地事务中完成幂等校验、资格校验、库存扣减、插入“发放中”状态的领取记录、标记资格已使用然后提交事务。第二阶段事务提交后发送 MQ 消息或者调用发放服务奖励发放成功后回调更新记录状态为“成功”发放失败则进入重试队列。学习环境里为了快速跑通可以直接同步发放奖励然后更新记录状态。但生产环境涉及现金、实物、券码等高价值权益时必须采用异步发放加回调确认的方式否则对账会很痛苦。注意事务里不要调用远程服务。看起来事务保证了“记录和发放一致”实际上远程调用超时时数据库连接一直被占用并发一高就会积累大量事务超时和锁等待。3.4 校验顺序为什么必须固定主流程中先做幂等检查再做活动校验、次数校验、资格校验最后扣库存。这个顺序不能随意调整。幂等检查必须放在第一位否则同一个请求重试两次时第二次请求会重新触发资格校验和库存扣减导致重复发放。库存扣减必须放在最后一步的前置因为库存是一个非常稀缺的资源只有前面所有资格条件都满足后才能去占用库存。如果把库存扣减放在资格校验之前就会出现没有资格的用户先扣掉一份库存资格校验失败后库存无法自动恢复的情况。4. 高并发下防超发和重复领取4.1 重复领取和超发的根源先看两个真实问题的根源。第一个是重复领取。用户快速点击领取按钮前端可能发出多个请求。如果每个请求都生成不同的biz_id后端就无法识别这是同一次点击最终同一个用户会成功插入多条领取记录。即使前端按钮置灰也不能完全依赖它因为异常重试、网络重放、脚本调用都可能绕过前端控制。第二个是超发。限量活动库存只剩最后一份时两个请求同时查库存都看到剩余量为 1然后都执行 update 把库存减为 0但实际上两个请求都认为自己扣减成功。解决超发必须让扣减操作具有原子性不能先查后改。4.2 Redis 分布式锁控制同一用户并发在数据库唯一索引之外可以使用 Redis 分布式锁让同一个用户在同一个活动上的领取请求串行化。这种做法的价值是减少无意义的数据库竞争。public ReceiveResult receiveWithLock(ReceiveRequest request) { String lockKey receive_lock: request.getActivityCode() : request.getUserId(); String requestId UUID.randomUUID().toString(); boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(3)); if (!locked) { throw new BusinessException(操作太频繁请稍后再试); } try { return receive(request); } finally { String value redisTemplate.opsForValue().get(lockKey); if (requestId.equals(value)) { redisTemplate.delete(lockKey); } } }这段代码有两个关键点。锁过期时间不能太短必须大于业务执行耗时否则业务还在执行锁已经过期下一个请求又拿到锁进入领奖流程。锁删除前要校验值只有当前线程自己写入的requestId才能删除避免误删别人刚获得的锁。Redis 锁是缓解手段不是兜底方案。因为 Redis 锁有极端情况下锁服务不可用、锁过期、主从切换丢锁等问题。所以数据库的唯一索引始终要保留作为最终防线。4.3 数据库唯一索引是最终兜底无论 Redis 锁是否生效user_receive_record表的uk_biz_id唯一索引都能保证同一个biz_id只能插入一次。即使两个请求同时到达第一个插入成功第二个插入会抛出唯一键冲突异常服务端捕获后返回“正在处理中”即可。这里要求业务设计必须让“一次点击”对应“一个biz_id”。前端要在初始化按钮点击时生成biz_id本地保存并随重试请求一起提交。如果客户端每次重试都重新生成biz_id唯一索引就失去意义。4.4 乐观锁与悲观锁对比库存扣减有不同的数据库实现方式下面是两种常见方案的对比。方案实现方式优点缺点适用场景乐观锁update ... set remain_count remain_count - 1 where remain_count 0无锁等待冲突时直接失败库存不足时无法排队等待先到先得、活动常规领取悲观锁select ... for update 后 update能避免并发覆盖持有行锁吞吐下降库存极小、必须保证绝对有序领取类活动绝大多数情况下适合乐观锁。用户看到库存不足直接返回“已领完”不需要排队。只有秒杀、限量抢购这类需要做等待队列的场景才考虑悲观锁并且要配合连接超时和事务时间控制。5. 运行验证与排错链路5.1 本地并发模拟本地启动服务后用下面的 Shell 脚本模拟 200 个用户同时点击领取按钮。这里同一用户使用不同的biz_id目的是验证“同一用户最多只能领取一次”的规则。for i in $(seq 1 200); do curl -s -X POST http://localhost:8080/api/receive \ -H Content-Type: application/json \ -d { activityCode: zsff_2025, userId: 10001, bizId: click-10001-$i-test, channel: APP } done wait跑完后查询数据库统计该用户在该活动下的领取记录SELECT status, COUNT(*) FROM user_receive_record WHERE activity_code zsff_2025 AND user_id 10001 GROUP BY status;预期结果是只有 1 条状态为成功的记录其余请求要么被幂等拦截要么在个人限领次数校验时抛出异常。如果查询结果出现多条成功记录就需要回头检查biz_id是否每次都不同以及唯一索引是否已经创建。再验证同一个biz_id的幂等性连续提交同一个请求体预期只有第一条插入成功后面的请求都返回已有记录而不会重复发放。5.2 对账脚本发现漏发和错发上线后不能只靠接口正确还要有对账机制。最简单的一个对账原则是成功发放记录数加上剩余库存数必须等于活动配置里的初始库存数。下面这条 SQL 可以找出不一致的活动。SELECT a.activity_code, (SELECT COUNT(*) FROM user_receive_record r WHERE r.activity_code a.activity_code AND r.status 1) AS success_count, a.total_inventory, (SELECT i.remain_count FROM activity_inventory i WHERE i.activity_code a.activity_code) AS remain_count FROM activity a HAVING success_count remain_count ! total_inventory;如果对账结果出现不一致通常有三种情况一种是扣了库存但发放记录没有成功插入事务回滚异常另一种是发放记录已插入但状态没有更新成功异步回调丢失还有一种是库存表初始值和活动配置表 mismatch比如建活动时没初始化库存行。5.3 常见问题排查链路问题现象常见原因检查方式处理建议同一用户重复领取成功缺少幂等键前端重试生成了新 biz_id唯一索引未创建查user_receive_record是否有重复记录查应用日志中每次请求的 biz_id一次点击固定 biz_id补唯一索引接口幂等检查前置库存变成负数扣减 SQL 没有加remain_count 0先查再改没有加锁查activity_inventory的 remain_count使用原子 SQL 扣减并带上库存大于 0 条件活动结束后仍能领取使用客户端时间判断服务器时区不一致活动状态未更新查看服务器时间、活动表 start_time/end_time/status统一使用服务端时间到点前定时更新活动状态事务超时或锁等待领取记录与外部发放放在同一事务远程发放耗时过长查慢 SQL、事务监控、调用链耗时事务内只落记录外部发放改异步已经扣库存但没有领取记录事务中库存扣减后代码抛异常但事务未正确回滚查接口日志、异常位置确认Transactional生效使用 declared exception 触发回滚资格名单用户提示没有资格资格表没导入数据活动编码不一致资格表状态被提前标记按 activity_code user_id 查资格表核对活动编码检查资格导入任务排查顺序要固定先看请求参数确认activityCode、userId、bizId是否正确再看数据库记录确认活动表和资格表是否存在对应数据然后看应用日志确认是抛异常还是正常返回最后看库存扣减 SQL 执行情况和事务日志。日志里必须包含biz_id这是串起一条用户请求的关键线索。6. 上线前检查清单与扩展方向6.1 领取系统上线前检查清单下面这份清单可以直接拿去评审使用。幂等键前端一次点击固定生成一个biz_id重试时复用后端接口有持久化幂等记录。唯一索引user_receive_record.biz_id和activity_qualification(activity_code, user_id)必须有唯一索引。库存扣减必须使用remain_count remain_count - 1且带remain_count 0条件的原子 SQL。时间边界活动校验使用服务端时间并且确认应用服务器时区与数据库时区一致。资格边界名单型活动确认资格表已导入资格被使用后不能重复领取。发放方式外部发放服务必须支持幂等发放失败有重试机制。日志领取结果、失败原因、耗时、user_id、activity_code、biz_id 都要记录。对账上线后能按成功记录数与库存剩余量进行核对。监控领取接口 QPS、成功失败比例、发放失败率、库存消耗速度。回滚活动配置表提供“暂停”状态接口可以一键拒绝所有领取请求。6.2 扩展方向这套基础版本可以做三个方向的扩展。第一是支持周期领取。把领取记录的唯一索引从(activity_code, user_id)改成(activity_code, user_id, receive_date)接口里增加日期维度判断就能支持“每人每天领一次”。第二是接入消息队列异步发放。在本地事务提交后发送 MQ 消息发放服务消费消息执行发放再通过回调更新领取记录状态。这样发放失败时可以进入重试主题配合死信队列做人工处理。第三是抽象成奖励中心。把活动规则、奖励模板、库存、资格做成配置化运营后台创建活动后开发只需要配置奖励编码和校验脚本不需要为每个活动重新开发领取接口。核心还是这四张表和这一段流程只是把规则判断部分替换成可配置表达式。实际项目里最值得投入精力的不是把第一个活动的代码写得非常花哨而是把领取链路的数据结构、幂等约定、扣减方式和对账逻辑沉淀下来。下一个“真神复活”活动上线时只需要新增活动配置和资格名单后端代码几乎不用改。这才是这套设计价值的真正体现。
“真神复活”这类限时运营活动用户端看到的往往只有一个“领取”按钮后端却要处理资格校验、幂等控制、库存扣减、发放记录和对账核对等一系列问题。按钮点击一次看似简单生产环境里重复发放、超发、活动结束后仍可领取等事故绝大多数都出在这条链路上。本文以这类“可直接领取”的运营活动为背景设计一个最小可复用的奖励领取系统覆盖数据表建模、服务端接口流程、并发防超发、本地验证和对账排查。读者如果是后端开发、游戏服务端研发或电商活动研发可以直接按这套思路落地到自己的项目里再根据实际活动规则调整校验逻辑。整篇文章不是只讲理论核心是四个动作先拆清领取系统要解决什么问题再用建表 SQL 把活动、资格、库存、流水四类数据落库接着实现一个带幂等和并发控制的领取接口最后用并发请求和 SQL 验证结果并且给出排查路径。1. 先拆解“真神复活”活动里“领取”按钮背后的子系统链路1.1 活动领取场景并不只有“点击领取”这一种运营活动叫“真神复活”但技术实现不能只针对这一个活动。开发时要把活动抽象成通用能力否则下一个活动上线又要从头写一遍。常规活动场景至少有以下几类场景说明常见例子无条件领取活动时间内登录即可领取无需额外条件登录礼包、回归奖励资格名单领取运营提前导入白名单用户进入页面才能领内测资格、定向邀请奖励条件领取完成指定任务或达到关卡后解锁通关第 5 章后领取复活券限量领取活动总份数固定先到先得限量称号、限量和实体周边限额领取每个用户限制领取次数可叠加时间窗口每人每天领取一次不同场景对后端的要求完全不一样。无条件领取重点防重复名单领取重点校验资格限量领取重点防超发限额领取重点处理周期窗口。实际设计领取系统时不能只为一个活动写死逻辑而是把“领取资格、领取次数、库存、发放记录”拆成独立模块。1.2 三个边界条件最容易出事故任何“可直接领取”的活动本质上都要回答三个边界问题时间边界、次数边界、库存边界。时间边界是最容易踩坑的一层。活动页显示“活动进行中”但用户请求到达服务器时可能刚好过了结束时间。这种情况不能只靠前端按钮控制服务端必须用服务器的当前时间判断活动开始和结束时间。核心原则是以服务端时间为主前端时间只做展示。次数边界要比“是否领过”多一点。只是判断用户有没有领取记录还不够因为有些活动是每人每天可领一次有些是活动期间总共可领三次。领取记录表要能支持按时间窗口统计不能只靠一张状态位判断。库存边界在限量活动里是硬要求。用户看到页面有剩余库存点击领取时可能已经被别人抢完。这要求库存扣减必须是一个原子操作不能先用 select 查出剩余数量再在 Java 代码里判断是否大于 0然后再 update。因为并发请求会在“查出数量”和“更新数量”之间同时读到同一个剩余值。注意领取系统上线前先把这三个边界问题写在需求评审里。如果产品文档没有明确说明活动结束后如何处理进行中的请求、用户重复点击如何返回、库存扣完时是否允许排队后端必须主动找产品确认。2. 用四张表把活动、用户、库存、流水建模领取系统的数据模型可以拆成四张表活动配置表、用户资格表、用户领取记录表、活动库存表。核心原则是配置与库存分离资格与记录分离。2.1 活动配置表只描述活动是什么活动配置表存放活动编码、名称、时间范围、状态、每人限领次数和库存总量。设计这类表时要注意不要直接在这个表上扣库存否则一次库存变动就会锁住整条活动配置行影响活动信息的读取。CREATE TABLE activity ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL COMMENT 活动编码建议业务可读, activity_name VARCHAR(128) NOT NULL COMMENT 活动名称, start_time DATETIME NOT NULL COMMENT 活动开始时间, end_time DATETIME NOT NULL COMMENT 活动结束时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1进行中 2暂停 3结束, limit_per_user INT NOT NULL DEFAULT 1 COMMENT 每个用户限领次数, need_qualification TINYINT NOT NULL DEFAULT 0 COMMENT 是否需要资格名单, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_activity_code (activity_code) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;活动编码不要用自增主键暴露给业务入口建议使用固定字符串比如zsff_2025_anniversary这样日志里查问题非常直观。活动状态也要区分草稿、进行中、暂停、结束不能只靠时间字段判断否则活动临时下线时没有可操作的开关。2.2 用户资格表名单型活动必须单独建表无条件和名单型活动最大的区别是前者所有用户都可以领后者只有计算机里能查到的用户才能领。用户资格表就是用于存放这份白名单。CREATE TABLE activity_qualification ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未领取 1已领取, source VARCHAR(32) NOT NULL DEFAULT MANUAL COMMENT 资格来源, ext_info VARCHAR(1024) COMMENT 扩展信息如资格等级、批次号, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_qualification (activity_code, user_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;资格表加唯一索引(activity_code, user_id)是防止运营在导入名单时重复写入同时也是后续校验资格时能走索引查询的基础。这里要区分“资格是否使用”和“领取记录是否存在”资格表只关注用户有没有资格、资格有没有被消耗领取记录的明细则放在下一张表。2.3 用户领取记录表记录每次领取的幂等结果用户领取记录表是整个系统的核心表。它记录每一次领取尝试的结果而不仅仅是“谁领了奖励”。这张表同时承担幂等键存储和领取流水审计两个职责。CREATE TABLE user_receive_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL COMMENT 幂等键一次点击对应一个ID, activity_code VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, reward_code VARCHAR(64) NOT NULL COMMENT 奖励编码, receive_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0发放中 1成功 2失败 3已回滚, fail_reason VARCHAR(512) COMMENT 失败原因, UNIQUE KEY uk_biz_id (biz_id), KEY idx_user_activity (activity_code, user_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;biz_id是幂等键由前端在用户点击按钮时生成或者由后端在接收请求时生成。同一个用户连续快速点击如果前端每次都生成一个新 UUID那服务端无法识别这是同一次点击所以必须让“一次点击”在整个重试周期内使用同一个biz_id。user_receive_record表的唯一索引uk_biz_id是防重复发放的最后一道兜底。状态字段用“0 发放中、1 成功、2 失败、3 已回滚”而不是简单用一个布尔值。原因是发放奖励可能是异步过程接口先返回成功但后台发货回调失败时还要能更新状态便于对账。2.4 活动库存表独立表承担扣减操作限量活动需要单独一张库存表。库存表中只有活动编码、剩余数量和版本号三列。CREATE TABLE activity_inventory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_code VARCHAR(64) NOT NULL, remain_count INT NOT NULL, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_activity (activity_code) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;这张表不关心“一开始总量是多少”总量放在活动配置表里。这里只关心剩余量。扣减时要求原子地将remain_count减 1并且只有剩余量大于 0 才能扣减成功。后续会看到并发防超发的关键就在这条 update 语句上。3. 领取接口核心流程校验、幂等、扣减、发放3.1 接口定义与请求结构领取接口属于写操作建议使用 POST请求体包含活动编码、用户标识、幂等键和渠道信息。一个典型的接口请求结构如下。{ activityCode: zsff_2025, userId: 10001, bizId: click-10001-20250601093012-8f3a, channel: APP }bizId的生成规则可以没有统一格式只要能在一次点击的生命周期内保持一致即可。服务端接收请求后第一个动作就是用这个bizId查领取记录如果已经存在则直接返回成功结果不再执行后续逻辑。3.2 主流程代码实现下面这段代码使用 Spring Boot 的 Service 写法MyBatis 负责数据库访问。它按“幂等检查、活动校验、次数校验、资格校验、库存扣减、记录插入、资格标记”的顺序执行。Service public class ReceiveService { Resource private ReceiveRecordMapper receiveRecordMapper; Resource private ActivityMapper activityMapper; Resource private QualificationMapper qualificationMapper; Resource private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) public ReceiveResult receive(ReceiveRequest request) { // 1. 幂等检查同一个 bizId 只处理一次 ReceiveRecord existing receiveRecordMapper.selectByBizId(request.getBizId()); if (existing ! null) { return ReceiveResult.from(existing); } // 2. 活动规则校验 Activity activity activityMapper.selectByCode(request.getActivityCode()); LocalDateTime now LocalDateTime.now(); if (activity null || activity.getStatus() ! 1 || now.isBefore(activity.getStartTime()) || now.isAfter(activity.getEndTime())) { throw new BusinessException(活动不存在、未开始或已结束); } // 3. 领取次数校验 int receivedCount receiveRecordMapper.countSuccess( request.getUserId(), request.getActivityCode()); if (receivedCount activity.getLimitPerUser()) { throw new BusinessException(已达个人领取上限); } // 4. 资格校验 if (activity.getNeedQualification() 1) { Qualification qualification qualificationMapper.selectByActivityAndUser( request.getActivityCode(), request.getUserId()); if (qualification null) { throw new BusinessException(没有领取资格); } if (qualification.getStatus() 1) { throw new BusinessException(资格已被使用); } } // 5. 库存扣减 int rows inventoryMapper.decrease(request.getActivityCode(), 1); if (rows 0) { throw new BusinessException(活动库存已领完); } // 6. 插入领取记录 ReceiveRecord record new ReceiveRecord(); record.setBizId(request.getBizId()); record.setActivityCode(request.getActivityCode()); record.setUserId(request.getUserId()); record.setRewardCode(activity.getRewardCode()); record.setReceiveTime(now); record.setStatus(1); receiveRecordMapper.insert(record); // 7. 标记资格已使用 if (activity.getNeedQualification() 1) { qualificationMapper.markUsed( request.getActivityCode(), request.getUserId()); } return ReceiveResult.success(record); } }这里要注意两个细节。第一个细节是第 3 步的countSuccess统计的是状态为成功的记录而不是所有记录。如果发放失败重试失败记录不应该占用用户的领取次数。第二个细节是第 5 步库存扣减必须使用下面这种原子 SQL而不是先查询再判断UPDATE activity_inventory SET remain_count remain_count - 1, version version 1 WHERE activity_code #{activityCode} AND remain_count 0;这条 SQL 依赖数据库行锁保证原子性。只要剩余量大于 0并且更新影响行数为 1就表示扣减成功。并发场景下多个请求同时执行这条语句时只有一条可以成功把库存从 1 减到 0其他请求都会命中remain_count 0条件失败。3.3 发放奖励放在事务里还是事务外上面的示例把插入领取记录和库存扣减放在同一个本地事务里。但“发放奖励”这个动作在实际项目中可能是调用内部钱包服务、发放游戏道具、发送优惠券甚至是调用第三方物流发货。把这类外部调用放在事务里会让数据库事务持续时间变长也容易造成事务回滚后外部服务却已经发货成功的“幽灵发放”问题。推荐做法是区分两个阶段第一阶段本地事务中完成幂等校验、资格校验、库存扣减、插入“发放中”状态的领取记录、标记资格已使用然后提交事务。第二阶段事务提交后发送 MQ 消息或者调用发放服务奖励发放成功后回调更新记录状态为“成功”发放失败则进入重试队列。学习环境里为了快速跑通可以直接同步发放奖励然后更新记录状态。但生产环境涉及现金、实物、券码等高价值权益时必须采用异步发放加回调确认的方式否则对账会很痛苦。注意事务里不要调用远程服务。看起来事务保证了“记录和发放一致”实际上远程调用超时时数据库连接一直被占用并发一高就会积累大量事务超时和锁等待。3.4 校验顺序为什么必须固定主流程中先做幂等检查再做活动校验、次数校验、资格校验最后扣库存。这个顺序不能随意调整。幂等检查必须放在第一位否则同一个请求重试两次时第二次请求会重新触发资格校验和库存扣减导致重复发放。库存扣减必须放在最后一步的前置因为库存是一个非常稀缺的资源只有前面所有资格条件都满足后才能去占用库存。如果把库存扣减放在资格校验之前就会出现没有资格的用户先扣掉一份库存资格校验失败后库存无法自动恢复的情况。4. 高并发下防超发和重复领取4.1 重复领取和超发的根源先看两个真实问题的根源。第一个是重复领取。用户快速点击领取按钮前端可能发出多个请求。如果每个请求都生成不同的biz_id后端就无法识别这是同一次点击最终同一个用户会成功插入多条领取记录。即使前端按钮置灰也不能完全依赖它因为异常重试、网络重放、脚本调用都可能绕过前端控制。第二个是超发。限量活动库存只剩最后一份时两个请求同时查库存都看到剩余量为 1然后都执行 update 把库存减为 0但实际上两个请求都认为自己扣减成功。解决超发必须让扣减操作具有原子性不能先查后改。4.2 Redis 分布式锁控制同一用户并发在数据库唯一索引之外可以使用 Redis 分布式锁让同一个用户在同一个活动上的领取请求串行化。这种做法的价值是减少无意义的数据库竞争。public ReceiveResult receiveWithLock(ReceiveRequest request) { String lockKey receive_lock: request.getActivityCode() : request.getUserId(); String requestId UUID.randomUUID().toString(); boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(3)); if (!locked) { throw new BusinessException(操作太频繁请稍后再试); } try { return receive(request); } finally { String value redisTemplate.opsForValue().get(lockKey); if (requestId.equals(value)) { redisTemplate.delete(lockKey); } } }这段代码有两个关键点。锁过期时间不能太短必须大于业务执行耗时否则业务还在执行锁已经过期下一个请求又拿到锁进入领奖流程。锁删除前要校验值只有当前线程自己写入的requestId才能删除避免误删别人刚获得的锁。Redis 锁是缓解手段不是兜底方案。因为 Redis 锁有极端情况下锁服务不可用、锁过期、主从切换丢锁等问题。所以数据库的唯一索引始终要保留作为最终防线。4.3 数据库唯一索引是最终兜底无论 Redis 锁是否生效user_receive_record表的uk_biz_id唯一索引都能保证同一个biz_id只能插入一次。即使两个请求同时到达第一个插入成功第二个插入会抛出唯一键冲突异常服务端捕获后返回“正在处理中”即可。这里要求业务设计必须让“一次点击”对应“一个biz_id”。前端要在初始化按钮点击时生成biz_id本地保存并随重试请求一起提交。如果客户端每次重试都重新生成biz_id唯一索引就失去意义。4.4 乐观锁与悲观锁对比库存扣减有不同的数据库实现方式下面是两种常见方案的对比。方案实现方式优点缺点适用场景乐观锁update ... set remain_count remain_count - 1 where remain_count 0无锁等待冲突时直接失败库存不足时无法排队等待先到先得、活动常规领取悲观锁select ... for update 后 update能避免并发覆盖持有行锁吞吐下降库存极小、必须保证绝对有序领取类活动绝大多数情况下适合乐观锁。用户看到库存不足直接返回“已领完”不需要排队。只有秒杀、限量抢购这类需要做等待队列的场景才考虑悲观锁并且要配合连接超时和事务时间控制。5. 运行验证与排错链路5.1 本地并发模拟本地启动服务后用下面的 Shell 脚本模拟 200 个用户同时点击领取按钮。这里同一用户使用不同的biz_id目的是验证“同一用户最多只能领取一次”的规则。for i in $(seq 1 200); do curl -s -X POST http://localhost:8080/api/receive \ -H Content-Type: application/json \ -d { activityCode: zsff_2025, userId: 10001, bizId: click-10001-$i-test, channel: APP } done wait跑完后查询数据库统计该用户在该活动下的领取记录SELECT status, COUNT(*) FROM user_receive_record WHERE activity_code zsff_2025 AND user_id 10001 GROUP BY status;预期结果是只有 1 条状态为成功的记录其余请求要么被幂等拦截要么在个人限领次数校验时抛出异常。如果查询结果出现多条成功记录就需要回头检查biz_id是否每次都不同以及唯一索引是否已经创建。再验证同一个biz_id的幂等性连续提交同一个请求体预期只有第一条插入成功后面的请求都返回已有记录而不会重复发放。5.2 对账脚本发现漏发和错发上线后不能只靠接口正确还要有对账机制。最简单的一个对账原则是成功发放记录数加上剩余库存数必须等于活动配置里的初始库存数。下面这条 SQL 可以找出不一致的活动。SELECT a.activity_code, (SELECT COUNT(*) FROM user_receive_record r WHERE r.activity_code a.activity_code AND r.status 1) AS success_count, a.total_inventory, (SELECT i.remain_count FROM activity_inventory i WHERE i.activity_code a.activity_code) AS remain_count FROM activity a HAVING success_count remain_count ! total_inventory;如果对账结果出现不一致通常有三种情况一种是扣了库存但发放记录没有成功插入事务回滚异常另一种是发放记录已插入但状态没有更新成功异步回调丢失还有一种是库存表初始值和活动配置表 mismatch比如建活动时没初始化库存行。5.3 常见问题排查链路问题现象常见原因检查方式处理建议同一用户重复领取成功缺少幂等键前端重试生成了新 biz_id唯一索引未创建查user_receive_record是否有重复记录查应用日志中每次请求的 biz_id一次点击固定 biz_id补唯一索引接口幂等检查前置库存变成负数扣减 SQL 没有加remain_count 0先查再改没有加锁查activity_inventory的 remain_count使用原子 SQL 扣减并带上库存大于 0 条件活动结束后仍能领取使用客户端时间判断服务器时区不一致活动状态未更新查看服务器时间、活动表 start_time/end_time/status统一使用服务端时间到点前定时更新活动状态事务超时或锁等待领取记录与外部发放放在同一事务远程发放耗时过长查慢 SQL、事务监控、调用链耗时事务内只落记录外部发放改异步已经扣库存但没有领取记录事务中库存扣减后代码抛异常但事务未正确回滚查接口日志、异常位置确认Transactional生效使用 declared exception 触发回滚资格名单用户提示没有资格资格表没导入数据活动编码不一致资格表状态被提前标记按 activity_code user_id 查资格表核对活动编码检查资格导入任务排查顺序要固定先看请求参数确认activityCode、userId、bizId是否正确再看数据库记录确认活动表和资格表是否存在对应数据然后看应用日志确认是抛异常还是正常返回最后看库存扣减 SQL 执行情况和事务日志。日志里必须包含biz_id这是串起一条用户请求的关键线索。6. 上线前检查清单与扩展方向6.1 领取系统上线前检查清单下面这份清单可以直接拿去评审使用。幂等键前端一次点击固定生成一个biz_id重试时复用后端接口有持久化幂等记录。唯一索引user_receive_record.biz_id和activity_qualification(activity_code, user_id)必须有唯一索引。库存扣减必须使用remain_count remain_count - 1且带remain_count 0条件的原子 SQL。时间边界活动校验使用服务端时间并且确认应用服务器时区与数据库时区一致。资格边界名单型活动确认资格表已导入资格被使用后不能重复领取。发放方式外部发放服务必须支持幂等发放失败有重试机制。日志领取结果、失败原因、耗时、user_id、activity_code、biz_id 都要记录。对账上线后能按成功记录数与库存剩余量进行核对。监控领取接口 QPS、成功失败比例、发放失败率、库存消耗速度。回滚活动配置表提供“暂停”状态接口可以一键拒绝所有领取请求。6.2 扩展方向这套基础版本可以做三个方向的扩展。第一是支持周期领取。把领取记录的唯一索引从(activity_code, user_id)改成(activity_code, user_id, receive_date)接口里增加日期维度判断就能支持“每人每天领一次”。第二是接入消息队列异步发放。在本地事务提交后发送 MQ 消息发放服务消费消息执行发放再通过回调更新领取记录状态。这样发放失败时可以进入重试主题配合死信队列做人工处理。第三是抽象成奖励中心。把活动规则、奖励模板、库存、资格做成配置化运营后台创建活动后开发只需要配置奖励编码和校验脚本不需要为每个活动重新开发领取接口。核心还是这四张表和这一段流程只是把规则判断部分替换成可配置表达式。实际项目里最值得投入精力的不是把第一个活动的代码写得非常花哨而是把领取链路的数据结构、幂等约定、扣减方式和对账逻辑沉淀下来。下一个“真神复活”活动上线时只需要新增活动配置和资格名单后端代码几乎不用改。这才是这套设计价值的真正体现。
