脚本能不能长期跑下去，一半看代码，一半看网络这一侧配得对不对。最常见的问题是重试策略跟代理IP特性打架：脚本一失败就立刻重来，线路正好在抖动，重试把抖动放大成雪崩，最后脚本自己把自己压垮。两边要配着调，单独调一边都调不好。
重试的四个参数
- 首次间隔
- 失败后先等多久，建议五秒起
- 退避倍率
- 每次翻倍，别用固定间隔
- 次数上限
- 二十次左右，到顶就报出来
- 随机偏移
- 每次加零到三十秒，避免同步
为什么首次间隔不能太短？
线路抖动通常持续几十秒，一秒就重试等于在抖动最厉害的时候反复敲门。等到五秒，多数短暂抖动已经过去了，一次就能连上，总耗时反而更短。
退避倍率这一项在代理IP抖动的时候最容易被设成固定值。固定间隔在短故障时看不出问题，遇到长故障就会一直用同样的频率敲门，二十分钟能敲上千次。翻倍之后同样的时间里只敲十几次，压力小得多，也不容易触发对端的限流。
随机偏移的作用是打散，多实例同时掉线时尤其重要。五路请求按同样的退避曲线走，每次都在同一秒发起，看上去是一波一波的，很容易被注意到。给每个实例加一点随机，曲线就散开了，代价只是一行随机数。
次数上限要设，而且要有告警。一直重试会把日志刷满，真正的错误被埋掉；到上限停下来发一条告警，人看一眼往往比程序试两百次更快，也省得夜里被无意义的日志吵醒。
线路这一侧怎么配合
代理IP的并发上限要跟脚本的并发对得上。脚本开十个线程，线路只允许五条同时连接，另外五个就在排队，表现出来是随机的超时。先把脚本的并发压到线路容量以内，再谈重试。容量不够就该加线，把脚本并发压低只是临时手段，压得太狠进度也跟着掉。这两件事分开判断，才知道问题出在脚本还是在线上。
什么情况说明策略不对
三种表现：失败集中在同一时段、重试次数远高于失败次数、日志里同一个错误重复几百次。三种都指向策略问题，改代码比换线路有效。
要不要做探活
要做，而且跟重试分开。探活负责确认状态，间隔可以短；重试负责恢复，按退避走。两者混在一起，探活失败也触发重连，重连次数会虚高，看着像线路质量差。
长期跑还要看什么
看两样：每天的成功率和失败集中点。成功率稳定在九成八以上，说明策略合适；掉到九成以下就该查。失败集中点能告诉你问题在哪个环节，比重试次数有用得多，也比看总耗时直观。
还有一项是内存。脚本跑久了会有轻微的内存增长，一周之后可能撑不住。定时重启能缓解，但根治要看代码里有没有没释放的对象。
重启只是权宜，参数才是根子，两样都要看。
重试策略和线路容量对上了，长期跑才有意义，否则只是把故障推迟。这两项要一起调，单改一项容易调到另一个极端去，改完观察一周再动第二项。
重试是给线路留缓冲，不是给自己找事做。