做优惠券系统的同学，无论你在电商、本地生活还是零售行业，大概率都遇过这样的诡异事故：后台明明显示库存还剩5000张，用户却在前端看到“已抢光”；运营凌晨冲进群里喊“超发了”，技术却查不出是哪一行代码扣错了库存。我接手过一个年发券量过亿的活动平台，第一次全链路排查时发现，问题根本不在“领取那一下”，而在于从领取到核销的整条链路上，库存状态从来没有被当作一个联动体系来设计。
这篇文章不聊“用Redis DECR防超卖”这种正确但没用的话，我要讲的是：数据库存的优惠券库存，如何通过核销数据反向驱动库存调配，以及为什么我把“核销”而不是“领取”当作库存系统的真正心脏。
先给结论：优惠券库存的唯一真相不在缓存里，在核销流水里
很多人把优惠券库存当成一个“总数”，领一张减一张，用完拉倒。这是所有事故的源头。真正的优惠券库存管理，应该是四个状态在一条管道里流动：可领取配额、已领取待核销、已核销消耗、已过期/退回回补。哪怕你的数据库里只有一张券模板表，也必须有四个字段去分别承载这四个状态，而不是一个孤零零的“剩余库存”。
更反直觉的结论是：核销数据才是库存调配的触发器，领取数据只是预占。用户领券只是把一个名额从“可领取”挪到了“已领取”，这笔配额并没有真正消耗掉。只有当用户完成核销，系统确认这张券对应的权益实实在在用掉了，库存的“已核销”数才增加，同时“可领取”数才真正被锁定为消耗。如果用户领了之后一直不用直到过期，这个名额还要重新释放回池子里，供下一轮活动回收。这一进一出，才是库存联动的完整闭环。
我见过太多团队在“领取”环节堆满了各种高可用方案，Redis集群、Lua脚本、消息队列，却连一张核销流水表都没有。结果活动一结束，财务对账发现实际核销数比已发放数少了三万，运营两眼一抹黑，技术只能跑一个全表UPDATE把状态强行改掉，把账“平”上。这种平账，平的不是数据，是隐患。
背景与真实场景：为什么你总是查不出“库存去哪儿了”
2023年8月，我服务的某头部生鲜电商平台做过一次“满99减30”的大促券活动，预算20万张，通过App弹窗、短信、公众号推文三个渠道同时放量。活动开始40分钟，运营发现前端领券按钮变成了灰色，但后台数据库显示剩余库存还有23714张。运营以为是缓存延迟，刷新了三次依旧如此，只能紧急提工单。
技术排查后发现，领取接口走的Redis扣减逻辑没错，20万张的Key也确实被扣到了0。但数据库落库用的是异步批量任务，任务积压导致实际写入的已发放数字远小于Redis扣减数字。Redis把库存扣光了，数据库还没来得及记这笔账。这就是典型的“缓存与数据库账实不一致”：Redis认为库存已经发完，数据库认为还剩两万多。
事故本身并不复杂，但真正让人头疼的是后续处理：运营要求把Redis里多扣的库存“还回来”，技术却说不能直接改Redis，因为无法判断哪些用户是“已经领到但还没落库”的。双方僵持了一个下午，最后是写了一段临时对账脚本，把Redis的扣减流水和数据库的实际写入逐条比对，才把差额捞回来。这等于用手工方式做了一次分布式事务的补偿，耗时7个小时。
如果说领取环节的不一致还只是“账没记上”，那核销环节的不一致就是真金白银的亏损。同一个平台在2023年双11期间，把历史所有未核销的优惠券做了一个统计，发现账面上“已领取未使用”的券有143万张，但实际用户打开卡包能正常展示的只有128万张。那消失的15万张券去哪儿了？查到最后发现，其中9万张是用户退款后订单状态回滚，但优惠券状态没有跟着回滚，券被“吞”了；
另外6万张是用户在多个设备上操作，状态更新丢失，数据库里显示已核销，但用户卡包里仍然躺着这张券，还能继续使用。
这个案例告诉我们：核销数据如果不和库存系统做联动，它的价值就只停留在“记录一笔”的层面。而它本应该承担的任务是：驱动“已领取”状态向“已核销”状态迁移，同时反向告诉库存系统“这一个名额已经真正消耗，不会再回流”。核销流水就是这个迁移动作的唯一证据。
做数据库存设计时，我一直坚持一个原则：库存状态本身不存储业务动作，它只记录业务动作的结果。用户领券是一个动作，核销是一个动作，过期是一个动作，退款回补也是一个动作。数据库要做的，是记录这一连串动作产生的状态变化，并且在每个动作发生后，给下游系统一个可以感知的信号。
很多团队做不好库存调配，是因为他们把“核销”当成了一次普通的UPDATE语句：把user_coupon表里的status字段从1改成2。这种设计有三个致命缺陷：第一，没有流水记录，出问题后无法回溯；第二，没有事件通知，库存系统不知道核销发生了，也就无法做配额释放或消耗统计；第三，没有幂等保护，同一个核销请求重试两次，库存被扣两次。
拆解误区：那些看起来正确、实则埋雷的做法
我见过不少开发者的第一版设计是这样的：coupon表里有一个stock字段，用户领取时UPDATE stock = stock – 1 WHERE stock > 0，成功了就返回券。这个设计在小流量内部工具型系统中完全没问题，但只要进入营销场景，立刻会被打穿。因为这种设计没有区分“已领取”和“已核销”，也没有“过期释放”的概念。一旦用户领了不用，库存就永久沉没在“已领取”里，运营永远算不清真实的可发量。
一个更专业的做法，是把库存拆成四个维度去看：总预算、可领取数、已领取数、已核销数。总预算在活动创建时固定；可领取数等于总预算减去已领取数；已领取数包含已核销和待核销；已核销数用来衡量活动的真实消耗。这四个数字可以通过两张表算出来，一张是券模板汇总表，一张是用户券明细表。用户券明细表里每个用户一张券，状态字段标记为待使用、已使用、已过期、已退回。库存的四个维度，全部由明细表的状态聚合而来，而不是单独维护一个“拍脑袋”的库存数字。
Redis确实快，DECR一条命令在那个量级下不会超卖。但Redis扣减最大的问题，是它不产生业务语义。Redis只知道“这个Key的值从10变成了9”，它不知道这1个数字代表的是一个用户领走了一张券，还是同一个用户重复领了两次。更麻烦的是，Redis扣减成功之后，如果数据库落库失败，你就面临一个“消失的库存”：Redis认为已经扣掉了，数据库认为还没发放，两边永远对不上。
我见过有的团队为了处理这个问题，在Redis里同时维护两个Key，一个叫“剩余库存”，一个叫“已领取集合”，用SADD来判断用户是否重复领取。这个方案能挡住一部分问题，但根本矛盾没解决：Redis和MySQL之间没有事务边界，数据的最终一致性必须靠对账来兜底。任何声称“Redis可以防超卖”的方案，都只是在并发控制层面防了“穿透”，并没有在数据一致性层面防住“错账”。
这是最贵的一个误区。核销的本质，是一次涉及订单系统、券系统和库存系统三方的状态机迁移。用户下单使用了优惠券，订单系统需要知道这张券已经被占用；券系统需要把用户券的状态从“待使用”改成“已使用”；库存系统需要把“已领取待核销”的数字转换为“已核销消耗”。三个系统之间必须通过一个唯一业务键来回溯，比如order_id + coupon_code的组合。
很多团队把核销简化为“改一个状态字段”，省掉了核销流水表，省掉了幂等键，省掉了状态机。结果订单退款时不知道怎么把券还回来，用户重复提交核销请求时不知道怎么防重，财务对账时找不到每一笔核销的证据。这些问题叠加在一起，库存系统就完全失去了“联动调配”的能力，变成了一堆无论如何都无法自洽的数字。
专业判断逻辑：四张表、一个状态机、一道对账任务
我做优惠券库存系统，核心只依赖四张表。第一张是券模板表，字段包括活动ID、总预算（total_quota）、已发放数（issued_count）、已核销数（used_count）、版本号（version）。版本号用于乐观锁控制，更新时带上version条件，防止并发覆盖。第二张是用户券表，字段包括用户ID、券模板ID、状态（1待使用/2已使用/3已过期/4已退回）、领取时间、核销时间、关联订单号。
这张表的每一行代表一张真实的券，状态变迁必须走状态机。第三张是核销流水表，字段包括流水ID、用户券ID、订单号、核销时间、幂等键。每一笔核销都必须写流水，幂等键用order_id + user_coupon_id拼接，重复提交时直接拒绝。第四张是库存对账任务表，记录每次对账的时间、Redis库存快照、MySQL库存快照、差额、处理状态。
这四张表之间通过外键逻辑关联：用户券表的template_id指向券模板表，核销流水表的user_coupon_id指向用户券表。所有统计报表，都从明细表聚合而来，不另建冗余库存数字。唯一允许冗余的是券模板表里的已发放数和已核销数，因为它们是高频读取的低频更新字段，可以用异步方式从明细表汇总后写入。
用户券的状态迁移，我限定为四条合法路径：
除了这四条路径，任何状态跳转直接报错。所有的状态变更，都必须有一个前置动作事件，而不是“因为我要改所以改”。这样做的好处是：线上排查问题时，你可以从流水表把这个券的一生完整拼出来，什么时候领的、什么时候用的、什么时候退的、什么时候过期的。我不止一次靠这套流水快速定位“用户说券没了”的问题，答案往往是“券已经核销了但前端没刷新”，而不是“系统把券弄丢了”。
领取动作触发的是“预占”，具体流程如下：
核销动作触发的是“真消耗”，流程如下：
其中“已核销数加1”这个操作，就是核销数据联动库存调配的关键点。它告诉库存系统：这个预占的名额已经确认消耗，不会再回流。这个数字在活动结束后，可以用来计算真实核销率和剩余预算的真实可利用率。
Redis再快也只是加速层，MySQL才是事实源。我设计对账任务的出发点是：不要求Redis和MySQL在任何时刻完全相等，但要求活动结束时一定相等。对账任务分三步：
对账任务不能只是“发现问题”，必须“自动修复一部分，人工干预一部分”。我在实践中发现，约有65%的差额可以通过自动脚本回补解决，剩下35%需要人工确认。如果没有对账任务，这些差额会在活动结算时集中爆发，变成财务无法解释的窟窿。
具体案例与数据观察：一次真实的库存联动调配实践
我服务过的一个连锁餐饮品牌，会员体系里有超过300万注册用户，每周三固定做“会员日”活动，发放满50减15的到店券。活动玩法并不复杂，但有两个特殊要求：第一，券的有效期只有48小时，过期自动作废；第二，券核销后，如果用户退菜退款，券必须能退回卡包继续用。这两个要求直接把一个“简单发券”的需求，推到了“全链路库存联动”的复杂度。
在改造之前，他们的系统是典型的状态字段流：用户领券时在Redis里扣一个数，核销时在数据库里改一个字段，过期由定时任务扫一遍，退款完全不处理。结果就是每周三活动结束后，运营要对账到凌晨两点，每周都会多出来一批“发了但查不到核销记录”的券，财务和运营天天扯皮。
改造分三个层次推进：第一层，把用户券表的状态迁移改造成状态机，加核销流水表，加幂等键；第二层，把Redis扣减和数据库落库之间加上异步对账任务，每次活动结束后自动比对Redis扣减总数和数据库发放总数；第三层，把核销事件接入库存系统，核销完成后发出“消耗”信号，触发券模板表的已核销数更新，同时把退款退券纳入逆向流程，自动恢复库存。
改造上线后第一个周三，我们没有直接切全量，而是先用10%的流量灰度跑了一周。灰度期间发现了两个问题：第一个是退款触发的事件里有约2%的概率会丢消息，导致券没有自动退回，需要靠定时任务补扫；第二个是库存系统监听到的核销事件有重复，幂等键没拦住，导致同一个核销事件把已核销数加了两次。这两个都是典型的分布式链路问题，不改状态机根本发现不了。
改造完成后的完整月度数据，对比改造前的平均值：券核销率从58.7%提升到64.2%，提升约5.5个百分点。过期未核销的券数量从月均11.3万张下降到8.1万张，降幅28.3%。库存对账耗时从每周三的凌晨2点完成提前到当晚10点前完成，财务可以不用熬夜。最明显的，是客服收到的“我领的券去哪儿了”类投诉工单，从月均140单下降到32单。
这不是一个惊天动地的效果，但它验证了我的核心判断：当你把核销数据当作库存调配的触发器，整个系统的数据自洽性会显著提升，运维成本会明显下降。核销率提升不是优惠券系统本身能解决的，它依赖运营策略和商品吸引力，但至少，系统不再成为核销率的天花板。
很多人以为核销率只和运营策略有关，我做完这个项目后有不同的判断：核销率和库存系统的可感知状态有直接关系。当系统稳定、券的状态实时可查、退款自动回补时，用户对券的信任度会提升，核销意愿也会增加。反之，当用户经历了一次“领到券但用不了”的故障，他对这个品牌后续所有营销活动的参与意愿都会打折。
另一个数据观察是：重复发券的概率降低后，真实核销率反而上升了。逻辑很简单，如果同一个用户领了两张一模一样的券，他大概率只会用一张，另一张过期核销不上，这在数据上会拉低整体核销率。库存联动做好之后，重复发放被拦截，真实人均券数下降，但整体核销率反而上涨。这说明优惠券库存的核心目标不是追求发得多，而是追求用得准。
不同情况下的行动建议：按你的业务体量和阶段选方案
如果你的系统是内部测试券、员工福利券，或者给合作伙伴定向发放的少量券，用户规模在几千以内，日发放量不超过几百，那你不需要为了“高并发防超卖”去上Redis。直接在用户券表上做事务性UPDATE，用乐观锁版本号控制并发，把状态机做好，把核销流水记清楚，就足够应对了。
这种情况下的行动清单分三步：第一步，确认用户券表有status和version字段；第二步，确认核销时有流水记录；第三步，确认过期有定时任务能扫描。这三步做完，这套库存系统的数据自洽性可以达到95分以上，完全满足日常业务审计需求。
如果你们每个月有2到5次营销活动，单次放量在5万到50万张之间，那就需要考虑Redis预扣加数据库最终落库的架构。这个阶段的核心任务不是追求极致的实时一致，而是保证活动结束时账实相符。你需要一个异步对账任务，在每次活动结束后自动比对Redis和MySQL的数据，差额超过阈值时告警。
这个阶段最容易犯的错误，是只做了领取扣减的一致性，没做核销回补的一致性。我建议至少在设计阶段就把核销流水表建出来，哪怕一开始不写代码，也先把表结构设计好，因为一旦业务量上来再补，成本会成倍增加。核销流水表的核心字段就是三个：user_coupon_id、order_id、幂等键。这张表的价值，会在退款退券、财务对账、库存回补三个场景中被反复验证。
像618、双11、平台级大促这种量级，单场放券量在百万张以上，同时多个活动并行，此时需要引入事件驱动架构，把核销、退款、过期当作独立事件发给下游系统。库存系统通过监听这些事件更新状态，而不是靠定时任务批量扫。
同时，库存要按渠道、人群甚至城市分桶。我在一个酒旅平台的项目里，把库存拆成了40个渠道桶，每个桶独立扣减，互不干扰。主库存只在活动创建时设定总预算，各分桶共享这个预算，但每个桶的消耗独立计算。这样运营可以一眼看出哪个渠道的核销率最高，技术也能在某个渠道的库存被恶意刷时做定向拦截，而不影响其他渠道的发放。
不同情况下的取舍：没有最好的架构，只有最合适的
很多开发者在设计优惠券库存时，第一个问题就是“我要不要用分布式事务”。我的回答通常是：不要用。除非你的量级小到可以忽略性能代价，否则分布式事务在大促场景下会成为吞吐瓶颈。更务实的路线是：Redis原子扣减保证不超领，MySQL异步落库保证最终一致，定时对账兜底修复。这个方案接受了一个短暂的“已领取但未落库”窗口，但不影响用户的实际体验，也不影响财务最终对账。
取舍的边界在于：如果你们的合规要求是“每一笔领取必须实时落库”，那只能放弃Redis预扣，直接走数据库行锁扣减，但要做好数据库主库的写入压力评估。如果合规要求是“活动结束后24小时内账实相符”，那Redis加异步落库加对账的路线完全够用。
Redis不是万能的，在优惠券库存系统里，Redis只应该承担“热点扣减”这一个职责，不应该承担“状态存储”的职责。用户券的状态、核销流水、库存汇总，都应该以MySQL为准。Redis里的Key只有两类的活：一类是活动维度的实时扣减Key，一类是用户维度的幂等标记Key。前者用DECR，后者用SADD。除此之外的业务状态，Redis一概不管。
这个取舍的意义在于：Redis集群宕机了，MySQL还在，用户券数据一条都不会丢；Redis重启后从MySQL重新加载Key，库存数据也能恢复。如果把业务状态也放进Redis，Redis一挂，整个系统就瘫痪了，这是一次显而易见的单点灾难。
核销事件传给库存系统，可以走实时MQ，也可以是定时批扫。我实测过两种模式下的差异：实时MQ模式下，库存系统感知核销的延迟在秒级；定时批扫模式下，延迟在分钟级。对于绝大多数营销活动来说，分钟级延迟完全够用，因为库存的回补和释放本来就允许有几分钟的滞后。只有在“实时库存展示给C端看”的场景下，才需要走实时MQ。
因此我的取舍建议是：默认先上定时批扫，等到明确出现“用户看到的剩余库存数量明显不准，运营投诉”时，再升级为实时MQ。不要在一开始就把系统复杂度拉满。
过期未核销的券，库存回补策略有两种主流做法：一种是把过期名额释放回总池，供后续活动继续发；另一种是过期名额冻结，只做统计展示，不参与二次发放。我通常建议运营侧采用第二种，理由是：过期未核销意味着用户对该券的“兴趣浓度”不够，如果立刻把名额释放回池子二次发放，很容易出现同一批用户反复领取反复过期，拉高运维成本，也降低活动数据的可信度。
如果一定要释放回池，建议增加一个“冷却期”，过期后72小时之内不回补，72小时之后如果名额仍在配额内，再释放。这个策略既避免了“秒过期秒重发”的尴尬，又不会造成预算浪费。具体场景、运营策略适合哪种回补，可以通过A/B测试决定。
从“扣库存”到“管账本”：一次思维方式的升级
写到这里，我想回到标题里的关键词：数据库存的优惠券库存，优惠券核销数据联动库存调配。大部分团队做不好这件事，不是技术能力不够，而是不知道库存不是“扣”出来的，是“对”出来的。你把优惠券库存当作一个数字去扣，它就会在你看不见的角落悄悄出错；你把它当作一本需要逐笔记账、定期核对、按状态机流转的账本，它就会变成一个稳定、可追溯、可调配的系统。
我建议任何一个正在设计或重构优惠券系统的团队，至少从今天开始做三件事：第一，检查自己的用户券表有没有核销流水表，没有就先补上；第二，把用户券状态迁移改成状态机，禁止裸UPDATE；第三，建一个每小时跑一次的对账任务，哪怕逻辑再简单，先把Redis和MySQL的差额统计出来。这三件事做完，你的库存账目大概率能在一个月内清晰一大半。
优惠券库存的最终状态，应该是每一张券都能在系统里被完整追溯：谁在什么时间领了它，谁在什么时间用了它，如果退了，又是哪一笔订单触发的。做到这一步，库存调配就是水到渠成的事，你根本不需要“设计”一个联动方案，因为每一笔核销数据天然就在驱动着库存往下走。
下一步，你可以拉出最近一次活动的数据，算一算“已领取数”和“已核销数”之间的差额，再对比一下退款订单中被核销掉但没有恢复的券数。你会发现，问题比你想象的多，但解决的路径也比你想象的清晰。
我负责的优惠券系统在领取时已经用Redis的DECR防止超卖，数据库里也有总数，但每到活动结算时，已核销的订单数和优惠券消耗数对不上，有时多有时少。我想搞清楚，这类问题是不是出在“核销后没有把数据回流到库存模型”这一环，一般排查时应该先看哪几张表、哪几条链路？
核心结论：优惠券库存对不上，通常不是Redis扣减不够快，而是库存只有“总数”一个口径，且核销后的数据没有参与回算。优惠券库存不是一个单一数字，而是四个状态的组合：可领取、已领取待核销、已核销、已过期/已退回。
只要系统里只有“领取时减一、核销时改状态”两步，就会漏掉过期和退款路径，账实不一致是必然结果。我在维护一个老系统时踩过这个坑。券模板表里只有一个剩余数量字段，用户退款后券回到了账户，但系统没有更新issued_count，结果运营再次把这张券发给别人，实际发出501张，账面停留500张。
活动结束时系统显示已领取500张，数据库统计已核销420张，运营认为是超发，实际上是账本漏了“退款后仍占用名额”这一条状态记录。
推荐的数据模型至少要有这些字段：券模板表（活动总预算total_budget、已领取数量issued_count、已核销数量used_count、已过期数量expired_count、版本号version），用户券表（用户ID、券模板ID、状态status、领取时间、核销时间、关联订单号），核销流水表（用户券ID、订单号、核销时间、幂等键）。
把核销当成一个“有幂等流水的业务事件”，而不是一个简单的UPDATE。核销动作应当拆成三步：写核销流水防止重复核销、更新用户券状态为USED、更新模板表的used_count。过期和退款也走同样的回写逻辑，四种状态才能在同一个账本里闭合。
排查建议：如果你现在库存对不上，先回答三个问题：核销流水有没有幂等键？过期未使用的券是否回补到可领取数？退款后的券有没有根据业务规则更新issued_count？如果三个答案都是否，那问题一定不在并发，而在这三处空缺。
我们系统核销后只是把优惠券状态改成已使用，库存端完全感知不到。运营想看不同渠道的核销效果，只能让我导数据再手工算。我想知道核销完成后，数据该怎么回流给库存系统，才能自动驱动渠道配额释放或者库存调配？
核心结论：核销不是终点，它是库存调配系统的驱动信号。核销数据只有被解构成“订单、时间、渠道、归属”四个维度，才有资格驱动下一轮库存调配。一次核销动作，至少携带三个信息：哪个订单用了这张券、在什么时间核销、这张券来自哪个渠道或批次。
运营要的不是一个“已核销数量”，而是“每个渠道还剩多少可发、核销率多少、哪批券该回收”。这些数据不回流，运营就只能靠导Excel判断。
推荐的最小联动链路：用户点击核销 → 写核销流水（幂等键唯一） → 更新用户券状态为USED → 更新模板表的used_count → 若启用了渠道配额，则根据核销事件调整该渠道的配额 → 领域事件通知报表和运营后台。我重构优惠券系统时，把“核销完成”定义为一个领域事件。
前端核销接口只管写流水和改状态，领域事件订阅方负责更新渠道配额、刷新活动看板，核销接口不会因为下游逻辑变多而变慢。库存调配不等于“减一或加一”，更常见的是“渠道之间的配额转移”。比如某渠道领出800张只核销200张，系统可以自动把其中400张释放给另一个核销率高的渠道，剩余100张保留观察。
这套逻辑放在事件消费端以后，运营改配置就能完成，不用开发写SQL。判断联动是否做好的标准很简单：运营后台能否实时看到“每个渠道当前剩余可发量”，且不用技术同学介入。能做到，就说明核销数据已经在驱动库存调配。
大促期间用了Redis预扣加异步落库，活动结束后发现Redis里剩余库存数值和数据库算出来的对不上，多几张或少几张。我知道数据库才是事实源，但总不能每次活动结束手动去改Redis。想请教有没有成熟的自动对账和修复方案，最好能说明具体流程和坑。
核心结论：Redis与数据库不一致是常态，不需要追求实时相等，但要有一套“以数据库为准的定时校准机制”，把误差控制在一个时间窗口内消失。Redis在优惠券库存里的角色应该是“可丢失的加速层”，而不是另一个事实源。
用户领券读Redis，写库走异步，Redis数值一定会因为补单、补偿、过期等因素产生偏差。正确姿势是：数据库聚合出真实剩余量，定期反向校准Redis。
建议流程：每10分钟跑一次对账任务 → 从数据库计算可领取数量（total_budget减去issued_count） → 与Redis中对应的key比较 → 超过阈值触发修正 → 修正写入修正日志。
踩过的坑：我第一次做对账时直接拿数据库总数覆盖Redis，结果覆盖动作正好撞上用户领券的并发请求，把刚扣减的key恢复成原值，用户看到“库存还有”但申请时失败。后来加了两层保护：一是只修正指定时间窗口内没有更新过的key，二是用Lua脚本做比较交换，确保覆盖的是预期值。
Lua修正逻辑思路（示意）：只有当当前Redis值等于对账前的快照值时，才写入数据库计算出的真实值，否则说明这期间有并发扣减，本次不修正，留给下一轮。这样能把“修正动作”和“正常扣减”错开，准确性明显提升。另外，对账任务一定要记录差异日志。每次修正都写一条审计记录，包含key、原值、新值、触发原因。
这样即使修正逻辑写错，也能从日志里挽回，不至于变成黑盒操作。
我们系统的优惠券是“领了就扣、用了就不还”。订单退款、用户退券、券过期等情况都占着库存不释放，运营想把券发给更多人，但库存余额一直是0。想搞清楚这些场景具体怎么设计回补逻辑，以及回补时会不会出现重复加库存之类的问题？
核心结论：需要回补库存的场景有四类，过期、退款取消、运营作废、对账修正。但每一类的回补语义不同，不能用“库存加一”一股脑处理。过期未核销：这是最直接的回补场景。
用户持有券超过有效期仍未使用，系统把user_coupon状态改为EXPIRED，同时将issued_count扣减、expired_count增加，配额回到可领取池。注意：过期只影响“已领取但没用”的部分，不影响used_count。退款取消：这个场景要分情况。
如果用户申请退款后，退回的券还可以继续使用，那用户券状态回到AVAILABLE，issued_count不变，不需要回补，因为这张券仍然占着一个“用户持有”名额；如果业务决定退款后券直接作废并回收预算，issued_count减一，可领取池加一。判断依据只有一条，这张券是否仍在用户手里。
运营主动作废：例如发现某批券被羊毛党批量领取，运营批量作废这些券。此时要记录作废原因，并通过“作废流水”回补库存。最重要的是避免运营对同一批券反复操作，导致同一次回补被执行两次，所以需要幂等键。对账修正：当对账任务发现已核销计数有误，修正时也要带correction类型的回补流水。
这类修正的业务风险和用户回补不同，应该单独区分记录，方便审计。回补的底层设计建议：回补动作必须生成一条反向流水，流水号携带幂等键，比如“user_coupon_id + 回补场景”。定时任务扫描到过期券时，先查这条流水是否存在，存在则跳过。
在这个前提下再扩展“可配置化”，让运营可以控制每个场景是否自动回补，而不是每次改代码。
读者评论
文章把核销作为库存心脏很有道理，我们之前只盯着领取环节，结果核销数据不一致导致对账困难。四张表和状态机的设计很清晰，值得借鉴。
作为运营，最怕活动结束后发现核销数和发放数对不上。文中提到的库存四状态和核销流水，确实能帮助我们看清真实的消耗情况，不再被表面的剩余库存误导。
Redis扣减和数据库落库不一致的痛点太真实了。我们就是靠临时写对账脚本救火，文章给出的流水表和幂等键设计，能从根源上解决这类问题。
把核销当作事件驱动库存调配，而不是简单UPDATE，这个思路很关键。作者提到的四个状态迁移路径和四张表设计，可以作为优惠券系统的参考架构。
遇到过用户卡包显示有券但核销不了的问题，最后查出来是状态更新丢失。文章提醒的订单退款回滚和幂等保护，都是非常实际的细节，收藏了。