批量任务里因线路原因失败的部分，直接重跑往往重复成功，也常常二次失败。失败重放要解决的是把可恢复的失败按批次、按时点重新放一遍，而且不重复产生业务影响。本文按四类输入、三步设计、两条约束讲批量环境里失败重放怎么定。代理IP线路的失败重放要先把失败原因分清，代理IP线路相关的失败只是其中一类，这一点决定了机制的设计范围。
四类输入：先判断哪些失败值得重放
第一类是连接类失败——线路不通、握手未完成、连接被拒。这类失败通常没有业务副作用，重放安全，收益也最大，占可重放失败的绝大多数。
第二类是超时类失败——请求已发出但没等到结果。这类失败最麻烦，因为业务侧可能已经处理成功，只是回执没回来。盲目重放会造成重复处理。
第三类是归属不符类失败——出口正确但被业务方按规则限制。这类重放没意义，得先换线路再重放，属于带条件重放。
第四类是数据类失败——线路没问题，请求内容本身有问题。这类重放只会重复报错，应该直接判定终局失败并转人工。
批量环境的第一步不是写重放逻辑，而是把失败原因分成这四类。分不出类，任何重放策略都只会放大混乱。分类的依据是任务日志里的错误来源与阶段标识，日志字段不够时，先把日志补齐再谈重放。
三步设计：收集、择时、限速
收集阶段定两个东西：一是失败记录的保存范围，二是保留时长。范围要包含足够做分类的字段，而不只是一条错误信息。字段至少要含失败阶段、错误类型、当时使用的线路、请求的时间戳四项。缺了这四项，重放时无法判断属于哪一类，也无法确认业务时效是否已经过期。
择时阶段定重放的时机。批量任务的重放不适合紧随失败立即做，也不适合攒到第二天。可行的做法是设两个时点：短延迟的即时重放用于第一类连接失败，长延迟的批次重放用于其他可恢复类型。即时重放次数要严格控制在一到两次，批次重放每天最多一到两轮，超过就会把临时故障拖成长期占用。
限速阶段定重放流量的量级。重放流量必须比正常流量优先级低，且要单独限一条线路承接，避免与实时业务抢资源。这一步常被漏掉，结果白天的故障因为重放又延长了一轮。
限速还要按时段调节。夜间时段可以放宽批次重放的上限，白天时段收紧；业务高峰时段直接暂停重放。把重放速率与业务时段绑定，是让重放不冲击实时任务的关键设计。
两条约束：幂等与终局
第一条是幂等。重放的前提是同一请求做两次不会出两份结果。幂等的实现通常在业务侧而不是线路侧，但机制设计时必须确认覆盖范围：只有幂等覆盖到的类型才允许重放，没覆盖到的走人工或跳过。
第二条是终局判定。重放必须有停止条件，否则失败会一直留在队列里。常见做法是按时间判定，而不是按次数判定——超过某个时间点，业务时效已经过期，重放成功也没有意义，此时应直接标终局失败并记录原因。
两条约束里，幂等决定重放安不安全，终局决定队列会不会无限膨胀。这两件事都要在机制设计阶段定死，事后补非常困难。
把重放做成可观测的一等对象
批量环境里的经验是，重放一旦不可观测就会失控。建议为它单独准备三个指标：当日重放总数、按类型拆分的重放成功率、由重放转为终局失败的总量。前两个看机制是否有效，最后一个看失败分类是否准确——如果终局失败的数量很高，多半是分类阶段就分错了。
重放记录要与原始记录形成关联，能通过一条重放记录找回它对应的原始请求。这个关联是排查重复业务问题时唯一的线索来源，缺失时事后无从追溯。批量环境里最常见的重放事故不是没重放成功，而是重放成功了却不知道重放了什么。
把重放单独统计之后，还能反向发现线路问题：如果某条线路贡献的重放量长期偏高，说明线路本身的稳定性有问题，这比等故障报告更早发现问题。失败重放机制最后的价值不只在恢复任务，也提供了一份线路质量的连续记录，代理IP线路的稳定性表现会在这份记录里逐步显形。
问：超时类失败到底能不能自动重放？
取决于业务是否幂等。有幂等保证就可以自动重放；没有就必须走人工核对，或者只重放到”查询结果”这一步——先确认原请求有没有生效，再决定要不要重发。
问：重放队列积压怎么处理？
先看积压的类型构成。如果以第一类为主，说明线路故障仍在持续，重放只是表象，先解决故障；如果以第四类为主，说明分类规则漏了，把这些项直接判终局失败，积压会立刻下降。