整点放票，前一分钟接口还很安静，后一秒同一个渠道重复推来几百次下单。限流不是为了拦客人，是为了别让一个渠道把整条链路占住，让别的入口连页面都打不开。要挡的只有那一分钟的斜率，不是一天的总量，所以额度怎么分、被挡的怎么返回、锁定多久释放，这三件事要提前定好。

一、先分清挡在哪一层。一共三层：整站入口、渠道接口、本方订单处理。整站入口挡的是所有来源，会把窗口和自助机一起挡掉，这一层不要拿来给单个渠道用。渠道接口按渠道给额度，本方订单处理按库存给额度。绝大多数限流只做在中间那一层，因为只有那一层能说出这个渠道在这一秒发了多少请求，事后也只有它能算占比。

二、额度按库存的一成给，不按对方说能带多少人。某渠道每秒下单请求上限按当时可售库存的 8%~15% 设，单次请求最多带 5 张票，同一账号两次请求之间设 30 秒间隔，1 分钟内重复请求超过 10 次按机器行为处理，直接拒绝并留一条记录。这几档不要一次配到位，先只放额度、不限动作跑一个整点，看请求分布落在哪几个渠道哪几秒，再往里收。

三、被挡的那部分要有确定的返回。被限流拒绝的请求要返回一个稳定的错误码，让对方能够重试，而不是当成失败直接关单。判据只有一条：同一个订单号在重试时拿回的是原来的处理结果，不是新落的一行。如果对方把超时当作失败另起单号，限流就变成了超卖的原因。这是限流最坏的副作用，必须在联调阶段就先验这一条，验过了再谈额度。

四、库存锁定的边界比限流更容易出事。统一说法是：请求进入处理队列时锁定，出票成功时扣减，90 秒未完成自动释放。释放区间给到 90~180 秒。短于 60 秒，会出现客人正在支付而库存已经被别人买走；长于 300 秒，成批的空请求能把库存全部锁住，页面显示有票但谁都买不到，这种状态在报表上看是超卖，实际一张都没卖出去。

五、放量口子要有，降级方向要定死。高峰前手动放大额度的口子留一个，按渠道分别给，同时写回退时间，一次不超过 10 分钟，到期自动回落。降级方向是停掉最外层的售卖入口、保留已经下单那部分的出票，不能反过来——已下单不出票，就是当天掉单数的直接来源。恢复时按渠道逐个放开，不要一次性全放，全放等于把同一分钟的斜率再制造一次。

限流配得好不好，事后只看两个数：高峰那一分钟内各渠道请求占比是否仍然均匀，以及当天超卖笔数和掉单笔数是否都为 0。前一个数说明额度分得合不合理，后一个数说明锁定与释放的边界对不对。这两个数比接口日志好用，日志只有出问题时的工程师会看，而这两个数每天值班都会看到，看到就能当天决定要不要动额度。