页面上那个余票数字是缓存出来的。刷新快一秒，多出去的不只是体验，还有可能超卖的几张。这个平衡不靠把有效期压到多小，靠把显示口径和成交口径彻底分开，两条链上做的事不一样。

一、缓存里放什么。直接放"可售数"这个整数的风险，是它会被人当判据用。可以放的是键加数量加版本号：键按票种、时段、渠道三层拆开，共享库存单独再一层，不能和渠道库存合成一个数。合成一个数之后，超卖查不出漏在哪一层，只能整段回滚。两层同名是更常见的错误，键名要区分开，出问题当天就能看出是哪一层在漏。版本号的作用是让人能问出"页面显示的那个数是哪一版的"，这个问题每天客服都要问一遍。

二、有效期给多少。热门时段五到十秒，冷门时段三十到六十秒，按同一时段的下单笔数分档，不要全场共用一个值。但有效期不是主要手段：库存扣减成功之后要主动让对应的键失效，等过期是兜底，不是策略。只做失效不做回填的组合也要小心，售罄页面会长时间显示零而实际还有余量，这个方向的偏差同样要付成本，只是付在销量上。取值改过一次，当天要看一眼命中率的变化，命中率反而掉下来说明失效动作把缓存打穿了，等于没缓存。

三、缓存不能当判据。真正决定能不能成交的那一步必须回源，在可售库存上做扣减并写流水，流水里带时段、渠道、请求时间。缓存只用来给页面写"还剩几张"。两个口径要在文档里分别命名：显示余量、成交库存。文档里只有一个"库存"词的团队，最后一定有人拿显示余量去做成交判断，超卖就是这么来的。回源那一步的超时上限给一到两秒，超了就报错，不把旧缓存当返回值交出去：拿旧缓存去判成交，等于默认允许超卖。

四、售罄边界。余票等于零和售罄状态位是两件事，状态单独一位，人工能不能打开另给一个开关，开关的每次操作记操作人。最后一张放出去之前的并发最容易超：两个请求同时看到一，都往下走。扣减要用条件更新，更新影响行数为零就当失败，重试一次仍为零直接回源校验，别让它把负数写进库存表。负库存要在当天闭园前清掉，不留到次日。人工打开过售罄状态的，当天要有人复核，复核人和复核时间记在同一条记录里，不留口头交代。

五、每天回看三个数。缓存命中率、扣减失败率、超卖笔数。超卖不为零，不要先去调有效期，先把回源那一步的锁查一遍——把有效期从十秒压到五秒，看起来少超一点，实际是把问题推到闭园对账那天。真发生超卖，顺序是：先把该时段的状态位置成不可售，再由值班经理逐单决定留票还是退，最后写事件记录，含时段、超出张数、处置人、处置时间。

先做哪一件：先把"扣减成功后主动失效"这一句补上，再谈有效期取值。两件事都做了还超，就去查共享库存那层的键有没有拆干净，多数时候是渠道层和总层被合成了一个数。