失败重试看起来简单，写起来容易出问题。重试次数多了，一个坏任务反复占位置；次数少了，本来能补回来的也丢了。加上代理IP这一层，还要多考虑一件事：换不换线路再试。
重试要考虑的三件事
第一件是次数上限。设一个总数上限，达到之后转人工或者转入待处理区，避免无限重试。第二件是间隔，连着立刻重试，碰上对方站点正在波动，多半还是失败；隔一段时间再试，成功的机会大一些。第三件是换不换线路，这一条和代理IP直接相关。
换不换的判断依据是失败的表现。连不上的那种失败，换一条线路往往就能过；拿到了内容但内容不对，换线路可能没用，要回头看解析逻辑。把这两类混着处理，重试就成了碰运气。
- 次数上限设一个总数，不要只在单个任务上循环
- 间隔逐步拉长，不要固定间隔死磕
- 连不上类的失败优先换线路
- 内容不对类的失败先查解析，不必换线路
哪些失败不该重试
有一类失败再试多少次都一样，比如目标页面已经不存在、参数本身写错了。这类要能识别出来，直接记为终态，不要进重试队列。识别的方式是看返回的状态，有明确的不存在信号的，就不必重试。
分类之后各自定规则
- 先分类 连不上、内容不对、目标不存在，三类分开
- 再定规则 不同类别用不同的重试次数和间隔
- 最后看结果 连续几轮都在重试同一批，说明规则要调
重试的记录怎么看
重试要留记录，记下每次尝试用的哪条线路。同一批任务如果在某条线路上反复失败，换到别的线路就好了，说明问题在那条线路上，不是任务本身。反过来，换了几条线路都失败，问题多半在任务侧。这份记录是判断的依据，缺了就只能靠猜。
记录里重点看什么
按线路的维度再统计一遍，能看出更多东西。某条线路上的失败率明显高于其他，先把它降权；几条线路都差不多，说明问题不在线路这一层，要往任务参数或者解析规则上找。这一步做完，重试的调整方向就清楚了。
重试之后还是失败怎么办
攒成一批之后统一看。单个失败看不出规律，一批放在一起，共同点往往很明显，比如都集中在一个页面类型上、都发生在某个时间段。代理IP线路类的失败和任务类的失败，会呈现不同的分布，集中看更容易分开。
重试写不好的根源，是把所有失败当成同一件事。分成连不上、内容不对、本身不存在三类，各自定规则，重试就从碰运气变成了有依据的处理。线路换不换，也就有了明确的判断标准。
按类别定规则，重试才有意义。先分清失败的类型，再谈重试几次。