做 YouTube 数据采集和视频自动化处理的人迟早会遇到同一个困惑代码里多线程、异步、协程都上了请求一多还是 timeout、断连甚至被对方限住。我整理“YouTube 海量视频并发”这个系列的时候发现很多问题不是出在语言或框架而是服务器多 IP 配置这一步没打牢。单台服务器往往默认只有一个 IP出站连接的端口数、TIME_WAIT、服务端限流都卡在单点上。这篇把服务器多 IP 配置从网卡绑定、源地址选择、策略路由到并发编排拆开讲清楚适合在做采集服务、批量视频信息处理或者单纯想把单机并发能力用好读明白的同学。1. 单 IP 并发先撞墙到底哪里堵1.1 一次出站请求所涉及的链路很多刚接触海量抓取的人会把并发数当成唯一的指标觉得“线程拉到 1000 请求就会更快”。实际情况是每次从你的服务器发到目标服务器的请求都要占用一对 TCP 四元组源 IP、源端口、目标 IP、目标端口。目标 IP 和目标端口基本是固定的比如某个视频站的数据接口都是同一个域名、同一个 443 端口等于四个元素里能变的只剩“源 IP”和“源端口”。单 IP 的情况下源 IP 也固定了能够变化的空间就只有源端口。这是最容易被忽略的第一堵墙。1.2 源端口不是取之不尽的Linux 默认的本地端口范围一般是这样sysctl net.ipv4.ip_local_port_range # 输出类似32768 60999这个范围里大概有 2.8 万个端口可用。对一个固定的目标 IP 和端口理论上同时能建立的连接数上限就是 2.8 万左右。听起来很多问题在于短连接断开后的 TIME_WAIT 状态。HTTP 请求如果走的短连接每次连接关闭后这个四元组会进入 TIME_WAIT 状态默认等 60 秒甚至更久才能安全复用。假设每秒建立 1000 个新连接那 60 秒里就有 6 万个端口被占用单 IP 的端口池根本扛不住。实际表现就是并发一高日志里开始刷Cannot assign requested address。这不是代码 bug是单 IP 的物理限制。我之前在一台机器上用单 IP 跑短连接请求QPS 刚过 800 就开始间歇性报错把日志拉出来看全卡在“分配不到本地端口”。换成每 IP 单独带连接池之后同样代码跑到了 3000 QPS 以上依旧很顺畅。1.3 服务端限流才是最先感受到的墙端口只是客户端侧的限制更直接的是目标服务器对单 IP 的访问频率限制。视频站对同一个 IP 的每秒请求数、连接数都有自己的窗口判断短时间请求太密集响应码直接就变了要么是 429要么弹校验页面。这时候你去调代码、改并发模型基本没有效果因为问题出在“这个 IP 已经不受欢迎了”。所以多 IP 不是为了显得厉害而是让出站流量在地理上和逻辑上被分散开每个 IP 都处在一个相对正常的请求节奏里。这也是为什么并发越高越早规划多 IP 越划算。2. 多 IP 落地从网卡绑定到连通性自检2.1 IP 资源从哪来在动手之前先盘点清楚你手上的 IP 是怎么分配的。物理服务器或者独服服务商通常会给一组 IP一般同网段或者同一个 VLAN。这种环境下把多个 IP 绑到网卡上是纯系统操作自由度极高。云服务器情况复杂一点。很多云主机的“多 IP”其实分两件事私网辅助 IP 和公网 EIP。如果你只在系统层面加了一个私网 IP但云控制台上没有把对应的公网映射绑定好出网依然可能走默认的主 IP。这个必须先去控制台把辅助私网 IP 和对应的公网 IP 绑定好再回系统里配置。否则后面验到一半会发现源 IP 根本没换会非常绕。2.2 把多个 IP 绑到网卡上的操作Linux 下临时加 IP 非常简单一条命令ip addr add 203.0.113.5/32 dev eth0 ip addr add 203.0.113.6/32 dev eth0这里用/32是因为单个辅助 IP 并不需要跟网卡所属网段保持一致只要本机知道这个地址属于自己就行。查看效果ip addr show eth0可以看到 eth0 下面挂着多个inet地址。如果想让配置重启后还在Debian/Ubuntu 可以在/etc/network/interfaces里加静态地址块CentOS/RHEL 系则建议用 NetworkManager 的方式管理。不管哪种方式最终目的都是让操作系统承认“我有这么多本地地址”。2.3 配完先自检一遍IP 加上去之后先别直接跑业务验证一下每个地址是否能正常出网curl --interface 203.0.113.5 https://api.ipify.org curl --interface 203.0.113.6 https://api.ipify.org--interface会强制 curl 使用对应 IP 作为源地址。如果两个接口返回不同的出口 IP说明基本网络层面已经通了。如果返回相同或者超时就需要检查路由表和云控制台绑定关系别等任务跑起来才发现。3. 出站源 IP 分配让流量真正按设计分散3.1 默认路由总会优先走主 IP多 IP 配好了很多人会直接开始跑并发然后发现目标服务器看到的来源 IP 还是原来那一个。这是整个多 IP 配置里最容易踩的坑。Linux 选择出站源地址时默认查主路由表如果没有特别指定往往优先使用主 IP或者说第一个配上去的地址。辅助 IP 只是“存在”不代表出站流量会自动用它。想让流量真正分散必须主动干预源地址的选择常见就两条路应用层绑定或者策略路由。3.2 应用层绑定源地址应用层绑定是最直接的做法代码里指定这次请求用哪个本地 IP。Python 的requests底层用的是 urllib3可以通过自定义 HTTPAdapter 来实现。import requests from urllib3.poolmanager import PoolManager from requests.adapters import HTTPAdapter class SourceAddrAdapter(HTTPAdapter): def __init__(self, source_ip, *args, **kwargs): self.source_ip source_ip super().__init__(*args, **kwargs) def init_poolmanager(self, connections, maxsize, blockFalse, **kwargs): self.poolmanager PoolManager( num_poolsconnections, maxsizemaxsize, blockblock, source_address(self.source_ip, 0), **kwargs, )用的时候一个 IP 建一个 Sessionsession_5 requests.Session() session_5.mount(https://, SourceAddrAdapter(203.0.113.5)) session_6 requests.Session() session_6.mount(https://, SourceAddrAdapter(203.0.113.6))之后所有走session_5的请求源地址都会是 203.0.113.5走session_6的请求源地址就是 203.0.113.6。这样做的好处是逻辑清楚跟并发框架解耦适合大多数脚本任务。3.3 策略路由把不同源地址引向不同路由表有些场景不适合改代码比如业务是 Java 起的或者中间还隔了一层分发服务。这时候用策略路由更合适核心思路是给每个源 IP 建一条独立的路由规则。假设网关是 192.168.1.1网卡是 eth0echo 100 ip01 /etc/iproute2/rt_tables echo 101 ip02 /etc/iproute2/rt_tables # ip01 用的路由表 ip route add 192.168.1.0/24 dev eth0 src 203.0.113.5 table 100 ip route add default via 192.168.1.1 dev eth0 table 100 ip rule add from 203.0.113.5 table 100 # ip02 用的路由表 ip route add 192.168.1.0/24 dev eth0 src 203.0.113.6 table 101 ip route add default via 192.168.1.1 dev eth0 table 101 ip rule add from 203.0.113.6 table 101这样任何源地址是 203.0.113.5 的流量都会去查 100 号路由表源地址是 203.0.113.6 的流量查 101 号路由表。即使业务代码里没有任何绑定逻辑也能达到分流效果。如果要按进程或者用户分还可以配合 iptables 打标记iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 100 ip rule add fwmark 100 table 100把特定业务账号的流量全部引到对应路由表运维层面会省很多事。3.4 两种方式怎么选方式侵入性适合场景主要注意点应用层绑定需要改代码Python、脚本、独立任务每个 session 只能固定一个源地址策略路由不需要改业务代码Java、多进程、不便改代码的服务要维护路由表出问题排查成本较高iptables 标记需要配置规则按用户、按进程隔离规则多了容易混乱我自己在线上环境里用最多的是“应用层绑定 per-IP 连接池”因为任务层本来就是我控制的代码里一个地方封装好后续加 IP 只需要改配置项。策略路由则用在一些不改代码的历史服务上效果也不错。4. 并发任务层与多 IP 的编排细节4.1 从“IP 池”到“每 IP 连接池”的抽象多 IP 配好之后真正的难点不是网络配置而是任务层怎么把 IP 用起来。最笨的办法是给每个请求随机分配一个 IP但这会导致同一个 IP 同时被几十个任务打照样触发限流。更好的做法是做一层“IP 配额”抽象每个 IP 维护一个独立连接池每个连接池同时允许的活跃请求数是固定的。任务队列拿到一条待抓取记录后先看哪个 IP 的当前活跃请求没到上限再从对应的连接池发请求。这个思路跟数据库连接池很像每个 IP 就是一个资源单位池子是并发窗口。流量不会集中在某个 IP 上也不会出现某个 IP 被闲置。4.2 代码里绑定源地址的两种写法用异步框架时aiohttp原生支持local_addr参数写起来很直接import aiohttp IP_POOL [203.0.113.5, 203.0.113.6, 203.0.113.7] connectors { ip: aiohttp.TCPConnector(local_addr(ip, 0), limit15) for ip in IP_POOL } sessions { ip: aiohttp.ClientSession(connectorconn) for ip, conn in connectors.items() }这样每个 IP 对应一个独立的aiohttp.ClientSession每个连接池最多 15 个并发。取任务时按 IP 的剩余容量分配async def fetch_one(ip, url): async with sessions[ip].get(url) as resp: return await resp.text()如果你用的是同步requests就按前文那个自定义 Adapter 的方式先按 IP 建好多个 Session再配合线程池分发。Java 系也类似核心逻辑都是“把源 IP 当作连接池的一个维度”。4.3 连接复用对源 IP 的影响HTTP keep-alive 能让同一个连接反复使用减少握手开销但对多 IP 策略有一个副作用连接一旦建立源地址就固定了后续所有走这条连接的请求都会带着同一个 IP。这本身不是问题问题在于很多任务层会误以为“发到同一台目标服务器的请求会自动轮换 IP”。如果你用了一个公共连接池连接池里只有一两条长连接那所有请求实际都是在重复消费同一个 IP。解决的办法前面已经提到了一定要按 IP 拆连接池让同一时间不同 IP 的连接池各有各的长连接。重试的时候也要注意某个 IP 触发限流后优先换一个空闲 IP 再试而不是同一个 session 里拼命重试。5. 2C4G 小机器到底能扛多大的并发5.1 瓶颈三维度带宽、CPU、内存很多人问过类似“2C4G 的实例能撑多少并发”的问题。说实话抛给任何技术博主都没法给一个固定数字因为瓶颈取决于任务类型。优先级最高的是带宽。视频站的海量抓取有两种典型场景一种是抓视频信息、评论、字幕等小体积元数据单响应可能只有几十 KB另一种是直接下载视频文件动辄几十 MB 到几个 GB。后者根本不是“并发”问题一个线程就能把带宽打满。前者才有讨论并发数的意义。第二是 CPU。TLS 握手非常消耗 CPU每建一个新连接都要完成一次完整的握手过程。2C 的机器每秒能完成的握手次数大概是几百到一两千具体看密码套件和 CPU 型号。如果你的代码里还做了大量 JSON 解析CPU 压力会进一步放大。第三才是内存。同步线程模型下每个线程默认栈空间可能占 8MB但实际上 Python 线程还要叠加解释器和业务对象的内存4G 内存跑 500 个线程会有点紧张。异步协程模型能省很多内存但依然会被 CPU 卡住。一个粗略的参考表任务类型单次响应大小2C4G 合理并发参考主要瓶颈元数据接口5-50KB200-600 并发请求CPU / 带宽视频文件50MB-2GB8-20 个下载任务带宽 / 磁盘 IO接口压测1-10KB1000-3000 QPS 量级CPU / 源端口5.2 值得调的内核参数几个参数在多 IP 并发里常见调一下效果立竿见影sysctl -w net.ipv4.ip_local_port_range1024 65535 sysctl -w net.ipv4.tcp_fin_timeout15 sysctl -w net.ipv4.tcp_tw_reuse1ip_local_port_range把能用的源端口扩大配合多 IP 之后端口空间翻倍的效果会被放大。tcp_fin_timeout缩短的是 FIN_WAIT 状态的时间让空闲连接更快释放。tcp_tw_reuse在客户端出站方向一般可以开但如果你这台机器还承担 NAT 转换稳妥起见先别开。5.3 怎么验证源 IP 真的分布开了配置完多 IP 之后不要只看业务日志要用网络层的数据说话。服务器上抓包tcpdump -nn -i eth0 host 目标服务器地址 and tcp port 443观察源地址分布是否均匀。或者用ss统计本地连接的源地址ss -tn | awk {print $4} | cut -d: -f1 | sort | uniq -c如果看到某个 IP 的连接数明显偏高说明任务层的负载均衡逻辑没有生效。我一般会把这个统计做成一个监控项跑上一段时间之后基本能看出整个 IP 池的使用情况。6. 这轮配置中踩过的坑6.1 加了辅助 IP 反而连不出去rp_filter 的锅有一段时间我在服务器上加了两个 IP其中一个怎么都 curl 不通查了半天发现是反向路径过滤。Linux 默认开启rp_filter会检查回包的源地址是否可达如果入站数据包的源 IP 在路由表里没有合理的返回路径直接丢包。查看sysctl net.ipv4.conf.eth0.rp_filter如果要临时关掉sysctl -w net.ipv4.conf.eth0.rp_filter0不过在云环境里更推荐去云控制台确认辅助 IP 是否已经正确关联到实例。很多辅助 IP 配不出去的根因是控制台绑定步骤没走完系统层面的修复治标不治本。6.2 出口 NAT 把应用绑定悄悄覆盖了云主机如果通过 NAT 网关出网应用绑定的源地址可能会在网关那一层被改写最终目标服务器看到的还是主 IP。这不是你代码写错了而是网络架构决定的。遇到这种情况需要去云控制台把多个公网 IP 映射到对应的辅助私网 IP 上或者使用服务商提供的多 IP 网关能力。简单说多 IP 要打通“系统 IP、私网 IP、公网 IP”三层映射少了任何一环都不算真正生效。6.3 TIME_WAIT 把端口吞光短连接高并发跑一段时间很容易碰到Cannot assign requested address。一开始我以为是并发数太高后来看ss -s才发现 TIME_WAIT 堆了上万个连接。即使有多个源 IP如果任务层复用了同一个连接池、疯狂新建短连接TIME_WAIT 依然会堆积。后面引入了两个手段一是按 IP 拆连接池尽量用长连接二是调整内核参数并开启tcp_tw_reuse。两者配合之后这个报错基本消失了。6.4 IPv6 优先级导致 IPv4 地址池闲置有次压测发现响应挺快但回去看源 IP 分布发现 IPv4 地址池根本没动静。原因是域名解析到了 AAAA 记录流量全走 IPv6 出去了。如果你的服务器配了 IPv6而目标站也支持DNS 解析时可能会优先用 IPv6。多 IP 规划如果只配了 IPv4就需要在应用层强制只解析 A 记录或者单独规划 IPv6 地址池别让两套机制互相打架。6.5 多 IP 不是无限提速券最后提醒一句多 IP 解决的是“请求来源分散”的问题不是“吞掉所有并发”的万能药。如果单个 IP 的请求节奏已经过于激进加再多 IP 也只是把风险摊开并没有从根上降低目标服务器的压力。我实际跑下来最好的效果是把每个 IP 的请求速率控制在不到限制线的七八成整体吞吐反而比全部打满更高因为重试少了成功率高了。服务器多 IP 配置这件事说到底不是网络命令合集而是和并发任务层协同的一环。IP 配好了任务层不懂得按 IP 做连接池隔离效果照样拉胯任务层设计得再漂亮IP 源地址没有真正分散开也会被单点限制卡死。把这两层联动起来才是这个系列真正想聊清楚的东西。下一篇文章我会接着写任务队列和失败重试的设计把这次的 IP 池跟并发编排完整串起来。