在使用异步后端框架Tokio和HTTP客户端hyper构建下游服务时，很多开发者都会遇到一个头疼的问题：当并发请求量上来时，突然出现连接池耗尽的错误，导致大量请求失败。我之前在做电商订单系统的积分对接模块时，就踩过这个坑，当时服务调用积分服务的接口，测试并发到80的时候，就不断报hyper::Error::PoolExhausted，整个下单流程直接卡住，后来查了资料和调优，才解决了这个问题，今天就把整个过程和经验分享出来。
一、问题场景还原：并发调用下游服务时的连接池崩溃
1.1 具体的错误现象
当时的场景是，订单服务每次处理用户下单，都会调用积分服务的接口，给用户增加对应积分。我一开始用的是hyper的默认Client，没有做任何配置，用ab工具压测，并发数设为100，请求的结果里，有超过30%的请求返回500，错误信息是“hyper::Error::PoolExhausted”，翻译过来就是“连接池用完了，没可用的连接”。
1.2 问题的根本原因
后来查了hyper的官方文档，才明白问题出在两个地方：一是默认的连接池参数太小，二是重试策略没做好，导致连接被无效占用。hyper默认每个主机的空闲连接数最多是10，总连接数不限制，但并发请求过来时，大量请求都在等连接，同时如果有请求失败，又会新建新的连接，旧的连接没及时释放，很快就把池占满了。另外，默认的keep-alive超时是90秒，这个时间太长，空闲的连接会一直占着池的位置，新的请求拿不到连接。
二、调优keep-alive策略：让连接活的刚刚好
2.1 为什么要调keep-alive
HTTP的keep-alive作用是，一次TCP连接可以多次用来发送HTTP请求，不用每次都新建连接，这样能减少TCP握手的开销，提升性能。但如果keep-alive的时间设的太长，空闲的连接会一直占着连接池，导致可用连接不够；设的太短，又会频繁新建和关闭连接，增加开销，所以要根据实际并发量调整这个时间，还有连接池的大小。
2.2 具体的代码示例：调优后的hyper Client
这里给出完整的Rust代码，技术栈明确是Rust + hyper 0.14 + Tokio 1.x，代码里每个配置都加了注释，说明为什么这么设：
// 技术栈：Rust + hyper 0.14 + Tokio 1.x
use hyper::Client;
use hyper::client::HttpConnector;
use std::time::Duration;
#[tokio::main]
async fn main() {
// 1. 构建HTTP连接器，配置TCP层的keep-alive探测，60秒发送一次探测包，确认连接还活着
let mut connector = HttpConnector::new();
connector.set_keepalive(Some(Duration::from_secs(60)));
// 允许服务端自动协商HTTP/1.1或HTTP/2，不用强制某一版本
connector.enforce_http(false);
// 2. 构建hyper Client，调整连接池的核心参数
let client = Client::builder()
// 每个下游主机最多保留20个空闲连接（根据下游服务的处理能力调整，比如下游支持50就设30）
.pool_max_idle_per_host(20)
// 空闲连接最多保留30秒，超过就关掉，避免长期占池（默认是90秒，调小更合理）
.pool_idle_timeout(Some(Duration::from_secs(30)))
// 总连接数限制为200个，防止并发太高时连接无限占用资源（默认不限制，这里设置合理上限）
.pool_max_size(Some(200))
// 把配置好的连接器传给Client
.build(connector);
// 接下来就可以用这个client调用下游服务了，比如积分服务的接口
let uri = "http://integral-service.example.com/api/add";
// 后续请求代码省略...
}
这里要注意，pool_max_size的设置，不能超过系统允许的文件句柄数，也不能超过下游服务的最大连接数，比如下游服务最多支持50个连接，那上游的pool_max_idle_per_host设20就够，设太高的话，下游会直接拒绝连接。
三、调优重试策略：避免重复消耗连接池
3.1 重试策略的坑
很多开发者遇到请求失败时，会直接重试，但如果没控制好，比如每次失败都重试，或者重试次数太多，会导致大量重复的请求，占满连接池，甚至给下游服务带来压力。比如我之前的问题，就是每次请求失败，不管是不是幂等的，都重试，导致连接被反复占用，池很快就满了。
3.2 具体的代码示例：带合理重试的请求
这里用tower-retry库，搭配hyper的Client，实现合理的重试，只对幂等请求重试，设置最多2次重试，避免无限占用连接：
// 技术栈：Rust + hyper 0.14 + Tokio 1.x + tower-retry 0.4
use hyper::{Request, Body};
use hyper::client::Client;
use hyper::client::HttpConnector;
use std::time::Duration;
use tower::ServiceBuilder;
use tower_retry::{RetryLayer, Policy};
#[tokio::main]
async fn main() {
// 先复用之前调优过的Client，省略连接器配置，和上面一样
let connector = HttpConnector::new();
let base_client = Client::builder()
.pool_max_idle_per_host(20)
.pool_idle_timeout(Some(Duration::from_secs(30)))
.pool_max_size(Some(200))
.build(connector);
// 配置重试策略，核心是三个点：
let retry_policy = Policy::default()
// 最多重试2次，总共1次初始请求 + 2次重试 = 3次请求，不会过度重试
.max_retries(2)
// 只在两个条件满足时重试：1. 请求失败；2. 请求方法是幂等的（GET/HEAD/PUT等，POST绝对不能随便重试）
.retry_if(|_req: &Request<Body>, result: &Result<hyper::Response<Body>, _>| {
matches!(result, Err(_)) && _req.method().is_idempotent()
})
// 两次重试之间间隔1秒，避免给下游带来瞬时压力
.backoff(tower_retry::ConstantBackoff::new(Duration::from_secs(1)));
// 把重试层加到Client上，得到带重试的客户端
let retry_client = ServiceBuilder::new()
.layer(RetryLayer::new(retry_policy))
.service(base_client);
// 现在用retry_client调用幂等的GET请求，失败会自动重试2次
let req = Request::builder()
.uri("http://integral-service.example.com/api/query/123") // 幂等的查询接口
.body(Body::empty())
.unwrap();
match retry_client.call(req).await {
Ok(res) => println!("请求成功，状态码: {}", res.status()),
Err(e) => println!("最终失败，已重试2次: {}", e),
}
}
这里要特别强调，POST请求是写操作，绝对不能随便重试，因为可能会重复插入数据，导致用户积分多算，只有GET、HEAD、PUT这类幂等的请求才能安全重试。
四、应用场景、优缺点和注意事项
4.1 应用场景
这种调优方法适合用Tokio + hyper构建的异步后端服务，特别是需要调用多个下游服务的微服务，或者高并发的API网关、中间件，当遇到连接池耗尽、请求失败的问题时使用。比如电商的订单、支付、用户模块，都需要调用多个下游服务，并发量高，对稳定性要求高。
4.2 技术优缺点
优点：调优后的连接池能合理分配资源，不会被少量请求占满，keep-alive的设置减少了建连开销，重试策略避免了无效占用连接池，提升了服务的并发处理能力和稳定性，不会因为少量请求失败导致整个服务崩溃。缺点：需要手动调整多个参数，不能一概而论，比如不同的下游服务，连接池的大小和keep-alive时间要根据实际情况测试，另外重试策略如果配置不当，会导致下游服务压力过大，甚至雪崩。
4.3 注意事项
- 连接池的参数要和下游服务匹配：比如下游服务最多支持50个连接，那pool_max_idle_per_host设20就够，不能设太高，不然下游会拒绝连接；
- keep-alive的时间要平衡开销：太短会频繁建连，太长会占池，一般设30-60秒比较合适；
- 重试策略要严格控制：只重试幂等请求，设置合理的重试次数（1-3次），不能无限重试；
- 还要注意Tokio运行时的配置：比如工作线程数，不要让Tokio的线程不够，导致任务排队，占用连接池。
五、总结
通过调整hyper的连接池参数和keep-alive策略，搭配合理的重试策略，就能解决异步服务中连接池耗尽的问题。我当时调优后，用同样的压测工具，并发数设为200，请求成功率达到99.9%，没有再出现连接池耗尽的错误，服务的稳定性提升了很多。调试的时候，最好用监控工具看连接数的变化，比如用Tokio的tracing库，或者Prometheus，这样能直观看到连接的使用情况，进一步调优参数。
评论
围绕“使用hyper与Tokio构建下游服务时连接池耗尽，调优keep-alive与重试策略”参与讨论