I
Member
线上服务偶发卡顿，查到最后经常是某个 HTTP 调用没设超时，或者重试把下游打垮了，requests 这套东西用对了能省很多半夜报警。
一、超时必须分开设。connect 超时管建连，read 超时管等响应，只设一个总超时会在慢响应场景下失控。我一般 connect 设 3 秒、read 按接口 P99 的两倍设，宁可快速失败也不要无限挂起。
二、重试要有退避和上限。requests 自带不重试，需要用 urllib3 的 Retry 挂到 HTTPAdapter 上，状态码只对 502、503、504 重试，POST 默认不重试，除非接口明确幂等。退避用指数退避加抖动，避免所有实例同时重试形成惊群。
三、连接池别用默认。默认连接数在高并发下很快耗尽，表现为间歇性连接失败，其实是池子满了。按并发量调 pool_connections 和 pool_maxsize，并用同一个 Session 复用，而不是每次请求新建 Session。
四、熔断要落在调用方。连续失败超过阈值就快速失败一段时间，给下游恢复窗口，熔断期间返回降级结果并打点告警，而不是让请求继续排队。
你们线上 requests 超时一般设多少？有没有被重试放大过故障？
一、超时必须分开设。connect 超时管建连，read 超时管等响应，只设一个总超时会在慢响应场景下失控。我一般 connect 设 3 秒、read 按接口 P99 的两倍设，宁可快速失败也不要无限挂起。
二、重试要有退避和上限。requests 自带不重试，需要用 urllib3 的 Retry 挂到 HTTPAdapter 上，状态码只对 502、503、504 重试，POST 默认不重试，除非接口明确幂等。退避用指数退避加抖动，避免所有实例同时重试形成惊群。
三、连接池别用默认。默认连接数在高并发下很快耗尽，表现为间歇性连接失败，其实是池子满了。按并发量调 pool_connections 和 pool_maxsize，并用同一个 Session 复用，而不是每次请求新建 Session。
四、熔断要落在调用方。连续失败超过阈值就快速失败一段时间，给下游恢复窗口，熔断期间返回降级结果并打点告警，而不是让请求继续排队。
你们线上 requests 超时一般设多少？有没有被重试放大过故障？