Ruby Async::HTTP::Client如何限制连接池最大连接数？

Async::HTTP::Client是Ruby异步生态中广泛使用的HTTP客户端，它基于async-io实现非阻塞网络请求，性能非常出色。但在高并发场景下，不少开发者发现一个问题：如果不加限制，客户端会为同一个主机打开大量TCP连接，连接数可能达到成百上千，远端服务器可能直接返回连接被拒绝的错误，甚至触发对方的限流策略。这个问题的根源在于Async::HTTP::Client的连接池默认没有最大连接数上限。本文将详细分析连接池的工作机制，并给出几种限制最大连接数的实用方案。

理解Async::HTTP::Client连接池的工作原理

Async::HTTP::Client内部维护了一个ConnectionPool对象，每次发起请求时，客户端会先尝试从池中借出一个可复用的连接。如果池中没有空闲连接，且没有达到任何限制条件，客户端会直接新建一个TCP连接。关键点在于：默认的ConnectionPool使用了unbounded模式，也就是无上限模式，只要并发任务需要连接，池就会不断创建新连接，直到操作系统文件描述符耗尽或远端拒绝连接为止。

这种设计在一般场景下问题不大，因为async任务切换很快，少量连接就足够服务大量请求。但如果你的代码中有几千个并发任务同时发起HTTP请求，而每个任务都持有一个独立连接，那么瞬时连接数会瞬间飙升。很多反向代理默认只允许单个客户端IP建立100个左右的并发连接（例如Nginx的默认配置），超过就会返回502或504错误。

因此，限制连接池最大连接数本质上是在控制并发请求规模，让排队等待的逻辑发生在客户端，而不是把压力全部抛给服务端。

方案一：使用Semaphore信号量限制并发请求

最直接的做法是使用Async::Semaphore包裹请求逻辑。信号量可以保证同一时刻最多只有N个任务真正持有连接并发起请求，其他任务会排队等待。由于连接池会复用已完成请求归还的连接，实际建立的连接数不会超过信号量的上限。

require 'async'
require 'async/http/client'
require 'async/semaphore'

endpoint = Async::HTTP::Endpoint.parse('https://api.ipipp.com')
client = Async::HTTP::Client.new(endpoint)

# 限制同一时刻最多20个并发请求
semaphore = Async::Semaphore.new(20)

Async do |task|
  100.times.each do |i|
    task.async do
      semaphore.async do
        response = client.get("/items/#{i}")
        puts "#{i}: #{response.status}"
        response.close
      end
    end
  end
end</code>

这种方式的好处是简单直观，而且可以精确控制并发规模。信号量本身是协作式的，不会粗暴地中断任务，只是在获取许可时阻塞（实际上是异步挂起），任务依然遵循async的事件循环调度。

需要注意的是，Semaphore应尽量复用同一个实例，不要在循环内部创建，否则每个任务都会拿到独立的信号量，限流失效。另外，如果你的客户端实例被多个协程共享，信号量也应该全局共享。

方案二：自定义受限的ConnectionPool

Async::HTTP::Client允许在构造时传入自定义的连接池实例，这是官方推荐的高级用法。async-http的源码中提供了Async::HTTP::LimitedConnectionPool或类似的受限实现思路，其核心是把无上限的池换成一个带信号量的池：

require 'async'
require 'async/http/client'

endpoint = Async::HTTP::Endpoint.parse('https://api.ipipp.com')

# 使用受限连接池，最多允许16个并发连接
pool = Async::HTTP::ConnectionPool::Limited.new(
  endpoint.protocol,
  endpoint,
  limit: 16
)

client = Async::HTTP::Client.new(pool)

如果你的版本中没有Limited实现，也可以手动包装ConnectionPool，在创建连接前先获取信号量许可，归还连接时释放许可。这种方案与方案一的区别在于：限制发生在连接层面而不是请求层面。当服务端支持HTTP/1.1的流水线或HTTP/2多路复用时，一个连接可以承载多个并发请求，此时限制连接数比限制请求数更精确，资源利用率也更高。

自定义连接池的缺点是依赖内部API，不同版本之间可能存在兼容性差异，升级gem时需要留意changelog。建议将封装代码集中在一个模块中，便于统一维护和测试。

方案三：结合请求级并发限制与连接复用的最佳实践

在实际项目中，推荐将限流逻辑与客户端生命周期管理结合起来。首先确保复用同一个client实例，而不是每个请求都新建客户端——新建客户端意味着新建连接池，之前的连接无法复用，限流也就无从谈起。其次，在请求完成后务必调用response.close或使用块形式的client.get(url) { |response| ... }，让连接能及时归还池中供其他任务复用。

一个完整的可复用封装示例如下：

class LimitedHttpClient
  def initialize(base_url, concurrency: 20)
    @endpoint = Async::HTTP::Endpoint.parse(base_url)
    @client = Async::HTTP::Client.new(@endpoint)
    @semaphore = Async::Semaphore.new(concurrency)
  end

  def get(path)
    @semaphore.async do
      response = @client.get(path)
      body = response.read
      response.close
      body
    end
  end

  def close
    @client.close
  end
end

# 使用示例
Async do
  http = LimitedHttpClient.new('https://api.ipipp.com', concurrency: 15)
  results = 200.times.map { |i| http.get("/data/#{i}") }
  http.close
end

关于并发上限的具体数值，可以参考经验公式：连接数上限应小于服务端单IP并发连接限制，同时留有余量。如果远端是Nginx且默认配置未改动，15到30通常是安全的取值；如果服务端支持HTTP/2，可以适当降低连接数，因为单个连接可以复用多个流。

最后提醒一点：连接数的监控同样重要。可以通过client.pool.inspect或统计Async::IO::Socket的实例数量来观察实际连接规模，在压测阶段验证限流是否真正生效，避免配置了限制却因为复用了多个客户端实例而形同虚设。

RubyAsync::HTTP::Client连接池修改时间：2026-08-31 12:49:03