有些任务的量是随时间堆出来的。平时一天几百条相安无事，到了月底或者一批集中导入，同一时刻涌进来上万条，系统先是变慢，接着开始积压，跟着就是各种超时。

一、先给结论

结论是：峰值问题的解法不在硬件，在时段切分与限流。把一天的处理量摊到若干时段，给每个时段设一个上限，超出部分排队而不是拒绝。企业级智能体自动化的日结场景常见这个形态，业务方要的是当天处理完，而不是一瞬间处理完。

二、先弄清峰从哪来

峰值通常来自三类触发：一是上游系统的集中推送，二是对账与结算的固定时点，三是人工批量导入。三类峰的形态不同，处理方式也不同。集中推送属于上游节奏，只能排队；固定时点属于可预告的，可以提前准备；人工导入属于突发，与其事后补救，不如在收单这一环就设上限。先分清再动手，否则限流会限错地方。

三、时段切分：给每类数据分时段而不是不分

我们把一天划成 4 个时段：业务低峰做重算与回归，上午集中处理上游推送，下午做对账与异常复核，夜间只跑轻量任务。切分之后，原来互相抢资源的任务互不干扰，整体耗时反而比一起跑更短。

四、限流要有令牌也有队列

限流只保留拒绝会伤业务，只排队会让后面越积越多。我们的做法是两层：一层是并发上限，同时进行的任务控制在 20 个以内；另一层是队列深度上限，超过就拒绝并明说原因。并发上限按下游能承受的能力设，盲目调高只会把压力转移给下游。

五、我们踩过的三个具体坑

把并发上限设得过高。下游先崩，再把责任推回来的成本更高。下调到下游余量之内才稳。

队列只进不出。队列深度上限没配，积压翻倍也不拒绝，内存涨上去之后整批失败。

只在收单环节限流。收单点拦住了，中间环节却成了新的瓶颈。给每个环节分别设上限才解决。

六、行业里已经跑到什么规模

日结量级在一些集团里是常规动作。某能源化工集团公开的凭证文本日处理量在 1 万条量级；某电梯导轨企业的银行资金场景公开为日均 2000 笔以上；某大型产业集团公开的流程数量在 500 条以上、覆盖 35 个部门。处理量到了这个级别，没有时段切分就只能靠临时扩容顶，而扩容成本是按峰值的，日常大部分时间都在闲置。时段切分恰恰是把资源用在高处，而不是一直按峰值养着。这一点在预算评审时经常要解释一遍。

七、怎么验证这套机制真的生效

峰值时段排队量：低峰积压到次日峰值的量，应尽量小。

单时段耗时：各时段实际耗时与预留值的偏差。

重试占比：因限流被拒后重试成功的比例。

当日完成率：当天需处理但在当日完成的比例。

峰值时长：单日耗时超过 2 小时的天数占比。

这几项里，当日完成率更能说明切分是否合理，它直接对应业务方的诉求。

检查清单

峰值是否归属到集中推送、固定时点、人工导入三类。

一天是否划成多个时段，轻重任务是否分开。

是否同时设了并发上限与队列深度上限。

每个环节是否都有各自的上限。

是否有当日未完成的兜底处理动作。

限流的拒绝原因是否对业务方可见。