从 503 错误到无忧请求：自动重试与代理切换的完美实现
引言
在之前的文章中，提到了通过 Requests 中的 Retry 类来实现自动重试的方法，感兴趣的读者可以去看一下。
文章中有一个读者提到了能否在重试的时候自动更换代理，研究了一下，可以实现。本篇文章分享一下实现方式。
思路
Requests 底层依赖 urllib3，urllib3 提供了连接池，可以自动管理连接，连接会在下一次请求被复用。
因为我们的连接使用了代理，连接池中的连接在初次连接的时候会先连接远程代理服务器，然后通过代理服务器发送请求，获得响应。
为了在每次重试的时候能够切换代理，无论连接池中可以存放多少连接，连接被使用完后，就不能被放回连接池了，因为如果放回去的话下次复用还是用的已经连接了上一个代理的连接，这样的话就无法切换代理了。
所以我的方案是，在每次连接使用完之后就关闭连接，让连接池重新创建连接使用。
代码
代码思路：
首先启用日志，方便后面分析代码执行流程。
继承两个连接池的类，覆盖释放连接方法，将将要释放到连接池的连接关闭。
将我们自己的连接池类覆盖官方的 urllib3.poolmanager.pool_classes_by_scheme 字典，在初始化连接池类的时候就会用我们自己的连接池类了。
覆盖 Retry 类的 increment 方法，更改连接池的代理参数，方便下一次建立连接的时候使用新的代理地址和端口，这里我本地起了两个代理服务器，端口分别是 8081 和 8082。
覆盖 is_retry 方法，这里是为了方便调试，永远返回 True，可以保证每次都重试，因为重试的条件不太好构建，所以这里返回 True 让它可以一直重试，便于验证逻辑。如果在正式使用的时候记得要去掉。
代码运行结果
从日志中可以看出，首先 starting new connection，新建了一个连接，连接到第一个代理服务器 127.0.0.1:8081，然后网站返回 503 状态码，在经过 is_retry 方法判断后，打印了重试逻辑，进入到下一次请求，并且关闭了上一次连接。
重试原有的连接，重新走之前的逻辑，先新建一个连接到我们设定的 8082 的代理服务器，然后继续之前原有的流程，网站返回 503 状态码，经过判断后，打印重试逻辑，进入到下一次重试。以此类推，因为我只有两个代理服务器，所以后面的重试逻辑走的都是第二个代理服务器。
代理日志
查看下面的代理服务器日志，第一次请求到了 8081 这个代理服务器，返回 503 响应，看时间，后面的两个请求都请求到了 8082 的代理服务器上面，间隔时间很短，很快就重试完了。
总结
以上代码仅限于通过部分代码改动实现需求，还有很多不完善的地方，完全不能在生产环境使用，本篇文章只是提供一个思路，可以用最少的代码实现自动重试，并且在每次重试的时候切换代理服务器，提高开发效率，减少重复代码，让大家能早点下班哈哈。
对了，再提一句，覆盖 Retry 类的 increment 方法可以让我们根据响应或者错误信息来判断本次请求是否需要重试，可以通过覆盖 increment 方法来自定义重试逻辑，重试起来更加的方便。
从以上代码可以看出 Requests 的代码具有高度模块化和可拓展性的优点，代码比较易于维护和理解。在需要其他功能时，可以通过继承并重写指定方法来实现我们自己的逻辑，轻松添加自定义的功能，而不需要改动原有的代码，这点还是值得好评的。
版权声明: 本文为 InfoQ 作者【LLLibra146】的原创文章。
原文链接:【http://xie.infoq.cn/article/9a89500b7f13b4b3c1bd531ac】。未经作者许可，禁止转载。
还未添加个人签名 2018-09-17 加入
还未添加个人简介
评论