WebSocket外汇行情订阅：单连接到底能扛多少货币对？

做外汇行情API对接的团队，到了一定阶段都会被同一个问题卡住：WebSocket订阅到底能扛多少货币对？

我第一次认真面对这个数字，是在一次“把产品里28个主要货币对扩展成61个”的需求评审上。当时有同事非常笃定，说一个连接订阅一百多个货币对肯定没问题，WebSocket是长连接，不像REST要频繁握手；另一个同事坚持说行情推送是高频消息，货币对数量翻倍意味着推送量直接翻倍，很可能把连接撑爆。两人谁也说服不了谁，最后压测任务落到了我头上。这篇文章不是要给你一个绝对的官方数字，而是想把我自己从单货币对推到上百货币对的实测过程、计算逻辑和踩坑记录完整写下来，给同样在接外汇行情API、用WebSocket做实时订阅的人一个可复用的判断框架。

先说结论。WebSocket订阅能扛多少货币对，本质上不是一个由“连接上限”决定的数字，而是由三个指标共同决定的：连接数上限、单位时间消息密度、以及客户端服务端的处理速度。货币对数量只是输入参数，真正决定你卡在哪个环节的，是这三个指标里先被触顶的那一个。

1. “扛多少货币对”背后其实问的是三个指标

1.1 连接数、消息密度、处理速度是三道不同的坎

很多人在评估WebSocket容量时，第一反应是去看服务器最大连接数。这个思路在“用户同时在线”场景下是对的，但在外汇行情订阅场景下很容易产生误判。

我用一个例子说明：假设你的行情服务基于Node.js，单进程能撑住数万个空闲连接，这看起来很多。但外汇行情每秒都在产生tick数据，连接上是有持续流量的。一个连接在空闲时几乎不消耗CPU，但一个不断接收数据的连接就不一样了，每一条消息都要走完“接收→解析→分发”的完整链路。这时候，连接数上限早就不是瓶颈，消息密度才是。

消息密度又可以拆成两个变量：单个货币对的tick频率，以及你订阅的货币对总数。订阅列表从10对扩到50对，如果每个货币对的推送频率都是每秒5次，那消息量就是5倍。这个增长是线性的，看似好算，但外汇行情最大的特点就是不均匀，欧美盘重叠时段和新闻发布瞬间，tick频率可能瞬间放大10倍以上。所以你不能用“平均每秒几条”来估算，必须用“峰值每秒几条”来做预算。

处理速度就更好理解了：服务端推送再快，客户端解析不过来，消息就会在缓冲区堆积，堆积多了就会内存上涨、延迟拉高，最后触发心跳超时被服务端断开。很多“WebSocket扛不住”的现象，根因不在带宽，而在客户端处理不过来。

1.2 一个货币对的tick频率波动到底有多大

我觉得有必要把tick频率的波动说透，因为这个数据直接决定后续一切计算。

以EUR/USD这种全球流动性最强的货币对为例。在亚洲早盘比较清淡的时候，一秒钟可能只推送1~2次；欧洲时段进入活跃期，每秒能到5~10次；遇到美国非农数据、美联储利率决议这类事件，一秒钟推送几十次甚至上百次都不是新闻。GBP/USD、USD/JPY这类主流货币对的情况类似，只是数字会稍微小一点。

交叉盘和奇异货币对就完全不同了。EUR/GBP、AUD/NZD这类流动性一般的品种，平时可能两三秒才有一条tick，即使进入消息行情，也远达不到主流货币对的频率。所以当你听到别人说“我这个API订阅了200个货币对很流畅”的时候，要先问一句：你订阅的是流动性很好的28个主要货币对，还是把那些半天都不动一下的奇异货币对也算上了？这两者的负载差着一个数量级。

1.3 服务端对订阅数量往往会做隐性限制

还有一个很多人没注意到的坑：不少外汇行情API服务端，并不会真的允许你在一个连接里无限订阅。

有些平台有明确的单连接订阅上限，比如限制每个连接最多订阅100个或200个交易品种；有些平台不限制订阅数量，但会针对单个连接的带宽、消息速率做流控，超过阈值就直接断开并提示重连。更隐蔽的是，部分平台的文档写得很含糊，真正的限制只有在你订阅超过某个数量后才会触发，而且表现方式不是报错，而是“某几个货币对突然不推送了”或者“连接被静默断开”。

这类限制很难通过阅读文档发现，只能靠压测去试。我建议你在正式做容量规划之前，先确认三件事：平台是否有单连接订阅上限、是否有带宽或速率流控、断开连接时是否会返回明确错误码。这三件事不清楚就上线，后面排查问题的成本会非常高。

2. 单条tick消息的账本：带宽上限其实很容易算

2.1 一条典型报价消息的体积拆解

要估算“一个连接能扛多少货币对”，第一步是把一条tick消息的体积算清楚。很多人觉得这是小事，但正是在这个细节上，不同API的差异能大到5倍。

最精简的报价消息，通常包含货币对名称、买价、卖价、时间戳，可能还有卖价手数、买价手数。用JSON格式表示大概长这样：

json复制{"c":"EURUSD","b":1.12345,"a":1.12355,"t":1700000000123}

这里用了单字母字段名，已经是最紧凑的JSON写法了，算上标点大约60字节。如果字段名写得更直白，比如：

json复制{"symbol":"EURUSD","bid":1.12345,"ask":1.12355,"timestamp":1700000000123}

体积立刻涨到接近90字节。如果再带上hand sell、hand buy、原始报价来源、做市商ID这些字段，一条消息轻松突破150字节。所以谈论容量之前，先看数据格式，我必须强调这一点，因为很多团队换了字段全的API之后发现流量暴增，却怎么都找不到原因。

2.2 从1个到200个货币对的带宽推演

有了单条消息的体积，带宽计算就变成了简单的乘法。不过很多人会忽略WebSocket自身的协议开销，TCP层、IP层、TLS层的头，以及WebSocket数据帧和客户端掩码，每条消息还要额外加上几十字节。

我做了一个便于记忆的估算：按每条行情消息100字节计算，把WebSocket帧、TCP/IP头、TLS握手摊销全部算进去，实际线路上一条消息大约占120字节左右。

• 订阅10个货币对，平均每个每秒5条tick，每秒大约50条消息，带宽约6KB/s。
• 订阅50个货币对，平均每秒250条消息，带宽约30KB/s。
• 订阅200个货币对，平均每秒1000条消息，带宽约120KB/s。

三个带宽方案看下来，200个货币对也就相当于家中宽带一个零头，远不到网卡和带宽的瓶颈。所以我一直认为，纯从带宽角度讲，一个正常的WebSocket连接扛住几百个货币对没有任何问题。真正的问题从来不在带宽，而在消息频率突增时的处理能力，以及异常情况下的重连和堆积。

2.3 客户端解析成本往往是隐藏瓶颈

带宽不是瓶颈，那瓶颈在哪？我第一次压测的时候也天真地以为是带宽，后来发现CPU占用率率先飙起来了。

问题出在JSON解析上。每秒1000条JSON消息，每条都需要做字符串切割、字段提取、类型转换。如果你用的还是动态语言，比如Python或Node.js，这个解析过程会占据大量CPU。我用Python的json.loads测过，200个货币对平峰时段大约每秒700条消息，解析就要占掉一个核的三成以上；一旦进入活跃行情，tick频率翻倍，CPU占用率直接冲到70%以上，随后开始出现消息积压。

这不是危言耸听。行情客户端不应该对每条原始消息立刻做完整解析，更合理的做法是先做一次“轻量判断”，只提取关键的货币对和价格字段，等真正需要完整数据结构的时候再做全量反序列化。或者换一种思路，直接用解析效率更高的数据格式，比如API能提供CSV或二进制格式就优先用，但大部分外汇行情API只提供JSON，那就只能在解析代码上做优化。

3. 实测复盘：50对、100对、200对的真实表现

3.1 常规订阅阶段：50对以下非常稳定

我自己压测用的环境很简单：一台4核8G的云服务器，客户端用Go语言写了一个连接器，服务端用的是一家常见外汇平台提供的行情WebSocket接口。

订阅10个主流货币对的时候，整个过程非常平静。每秒大约50~80条消息，CPU占用率在5%以内，内存基本是一条直线，连接非常稳定。把这个数字扩大到28个主要货币对，也就是美元直盘加欧系、商品货币那些常见品种，消息量大概涨到每秒150~250条，CPU还是不足10%。这个阶段无论从哪个角度看，单个连接都很轻松。

扩展到50个货币对，开始有一些感觉了，但仍然在安全范围内。消息速率大概在每秒300条上下，我的Go客户端解析起来毫无压力，连接连续跑了十几个小时也没有出现断开。如果你只需要接入常用货币对，单个连接完全够用，甚至不需要做任何特殊优化。

3.2 加压阶段：100到200对之间开始出现症状

把订阅列表加到100个货币对之后，我明显感觉到了变化。常规时段每秒消息量在700~900条之间，行情活跃时能冲到1500条以上。这个消息量级下，带宽依旧没问题，但服务器的网络中断和客户端解析开始有压力了。

我用同样的Go客户端跑，CPU占用率大约是20%~25%，还算正常。但当我换成一个用Python写的模拟客户端来接收同样的数据流时，情况就完全不同了。Python版本的解析逻辑每秒只能处理500~800条消息，行情一活跃就积压。积压的消息全部堆在内存队列里，内存以肉眼可见的速度上涨。跑了一个小时后，内存从初始的300MB涨到了2GB以上，紧接着就出现了连接超时断开。

这个现象说明什么？说明100~200个货币对承载能力的分水岭不在服务端，而在客户端处理方案。只要客户端处理效率足够高，200对并不是问题。如果客户端写得不讲究，50对也会撑爆。

3.3 触及上限时的典型日志长什么样

触及容量上限时，系统通常不会在那一瞬间直接崩溃，而是先出现一系列小症状，再逐渐恶化。我把当时收集到的关键现象整理成三个典型趋势：

• 日志开始出现明显的延迟：本应立即处理的消息，处理时间从毫秒级拉长到几百毫秒，整个系统的实时性消失。
• 内存曲线持续上升不回落：这说明消费速度跟不上生产速度，队列在膨胀。这是最危险的信号，通常排在手忙脚乱的重启之前。
• 心跳对不上导致服务端主动断开：客户端忙不过来，连心跳都没空回，服务端认为连接已死，直接关闭连接。你会在日志中看到stream disconnected before completion: websocket closed by server before res这类提示。

看到这三个现象，基本可以判定消息处理链路已经饱和，需要做架构层面的调整，而不是单纯把连接数调大、超时时间延长来掩盖问题。

4. 比货币对数量更致命的坑：重连风暴与消息积压

4.1 “websocket closed by server before res”的来龙去脉

很多人在WebSocket订阅场景下见过这句话：stream disconnected before completion: websocket closed by server before res。字面意思是连接在完整响应之前被服务端关闭了，但实际触发原因五花八门。

我在排查过程中发现，这类断开最常见的有三种原因：

• 服务端主动回收空闲连接。大部分WebSocket服务默认有一个空闲超时机制，比如60秒或90秒内没有收到任何数据，就认为客户端已经死了。很多客户端只在刚连接时发一次订阅请求，之后就不管不顾了，到了第61秒，服务器直接把连接断掉。
• 客户端处理慢导致心跳延迟。服务器每隔一段时间发一个Ping帧，要求客户端在指定时间内回复Pong。客户端主线程全部用来解析行情了，Pong回得不及时，服务器判定超时将连接断开。
• 订阅了过多品种后触发服务端流控。单个连接的输出速率超过服务端设定阈值，服务端会主动断连来保护后端。这种情况通常不会在断开前给出任何警告。

这个报错之所以让人头疼，是因为它把所有复杂原因都折叠成了一句笼统的“closed by server”，你根本看不出到底是因为空闲、心跳还是流控。排查的第一步永远是先看服务器返回的关闭码和关闭原因字符串，正常的WebSocket协议会在关闭帧里携带status code和reason，很多平台的客户端库会对reason做了隐藏，导致排查时像瞎子摸象。

4.2 心跳机制才是保活的关键

在订阅场景里，正确处理心跳的价值比增加服务器配置高得多。

业界常用的WebSocket心跳方案有两种，一种是在应用层自己定义一条心跳消息，比如每30秒发一条{"type":"ping"}，服务端收到后返回{"type":"pong"}。另一种是使用协议自带的Ping/Pong帧，由客户端库自动处理，不需要业务层介入。我个人强烈建议优先使用协议自带的Ping/Pong，因为它简单可靠，不依赖业务消息优先级，而且不会被业务逻辑阻塞。

但这里有一个很容易踩的坑：很多客户端库的Ping/Pong处理是自动的，但自动发送Ping的间隔可能不符合服务端要求。比如服务端要求30秒内必须有数据，库默认60秒发一次Ping，那连接照样会被断开。所以接入任何行情API之前，先查两件事：服务端空闲回收时间是多少，客户端自动Ping间隔是多少。这两个数字不匹配，后面一定出问题。

我接入多个外汇平台的经验是：客户端主动发应用层心跳，每10~20秒一次，同时配置好底层Ping/Pong帧的双向响应。这不是浪费，是成本最低的保险。你永远不想在生产环境里靠“服务器断一个我重连一次”的笨办法去维持连接。

4.3 消息积压的耗尽策略：不要靠无限缓存

消息积压是另一个很隐蔽的系统性风险。当客户端处理速度跟不上推送速度时，如果代码里用的是一个无界队列，内存就会无限增长，最终把整个进程拖垮。

处理积压有几种常见策略，各有利弊：

• 丢弃旧消息，保留最新：适用于行情场景。价格是覆盖式数据，旧tick本来就没有意义，保留最新一条就足够。可以用一个“环形缓冲区”实现，或者干脆直接覆盖同一个全局变量。
• 丢弃新消息，等待消费者处理：适用于对数据完整性要求高的场景，但行情变化快，丢新消息意味着看到的价格滞后，体验很差。
• 消费者降级：当积压达到阈值时，自动切换到一个简化的处理流程，比如只更新当前价格缓存，不再写入数据库，也不做复杂的技术指标计算。等积压缓解后再恢复完整流程。

实际做行情订阅时，我倾向于把“积压触发降级”和“消息体主动瘦身”结合使用。积压一旦超过某个阈值，就暂时把每条消息的完整字段解析改为只解析币对和买价卖价，其他字段统一丢弃。这样消费速度能提升好几倍，积压很快就能消化掉。

4.4 Nginx代理对长连接的影响

少数团队会用Nginx把外部WebSocket请求代理到内部行情服务，这个方案本身没问题，但有几个参数不调你会一直很难受。

Nginx默认对HTTP请求有proxy_read_timeout 60s的限制，这60秒恰恰是WebSocket连接的头号杀手。WebSocket建立后如果长时间没有消息，Nginx会在60秒后主动断开连接，表现和“服务端关闭”一模一样。解决方案是把超时时间调大，同时设置正确的Upgrade和Connection头。下面是一段我在生产环境用过的配置片段，供参考：

nginx复制location /ws {
    proxy_pass http://backend_upstream;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    proxy_buffering off;
}

要注意proxy_buffering off这一行。WebSocket场景下如果开了缓冲，可能会导致数据没有及时转发到客户端，产生类似消息延迟的诡异问题。另外，如果你的客户端和服务端之间的网络中有其他企业防火墙、负载均衡设备，同样要检查它们对长连接的空闲超时设置，这是排障时最容易被忽略的环节之一。

5. 生产级订阅方案：频道拆分、批量推送与退避重连

5.1 把订阅列表拆成几个独立连接

压测做到最后，我的结论是：从容量角度看，一个连接扛几十到一两百个货币对都不是问题；但从稳定性角度看，全世界都挤在一个连接里的风险很高。

你可以想一下这个场景：某个货币对的数据源突然出现异常，服务端处理这个品种的消息卡住，整个连接上的其他所有货币对都会受影响。如果所有消息都在一个连接里，一个品种出问题等于全盘掉线。这就是我为什么建议在生产环境按“频道”拆分连接。

具体的拆分方式可以参考下面的思路：

• 主连接：订阅流动性最好的十几个主要货币对，保证核心行情稳定。
• 次级连接：订阅交叉盘和次要货币对，这类品种消息密度低，但品种数量多。
• 单独连接：如果业务需要订阅黄金、原油等商品和指数，最好单独开一个连接，因为它们的行情特征和外汇报价差异很大。

这样拆分的最大好处是故障隔离。次要品种的数据源崩了，主连接上的核心品种不受影响。对多数交易系统来说，核心品种的可用性远比品类齐全重要。更极端的场景下，你甚至可以让主连接和多路行情API同时建立，做数据冗余。

5.2 快照加增量更新，把消息量降一个量级

如果你觉得“订阅200个货币对就够悬了”，那想一下要订阅1000个货币对会怎样。这种情况在跨平台的聚合行情服务里非常常见，单纯的订阅推送已经不够，需要用数据工程手段来削减消息量。

消息量削减的常规手段是“批量快照+增量更新”。服务器不是每来一个tick就推一条独立消息，而是每500毫秒把这段时间内所有变化的货币对打包成一个批次消息推过来。原来每秒1000条的独立消息，合并之后可能变成每秒2个批次，每个批次里包含500个变更项。JSON数组形式的批次消息比独立消息更省空间，客户端的解析次数也是指数级下降。

如果API本身不支持批量推送，客户端就只能自己写聚合层：收到单条报价后先写入本地缓存，每500毫秒把变更批量提交给下游。绝大多数外汇API都提供“只推送有变化的品种”模式，这种模式天然适合做聚合，实际效果非常明显，带宽没有变，但下游的处理压力小了一大截。

5.3 断线重连的指数退避与订阅幂等

行情服务断线是必然事件，真正拉开差距的是断线后的表现。

我在压测时经常看到的现象是：一百个客户端同时断线，然后所有客户端都立刻尝试重连，服务端瞬间被重连请求打满，于是又一批连接被拒绝，客户端继续重连，陷入恶性循环。这就是典型的重连风暴。

解决方案很简单：指数退避加随机抖动。第一次重连等1秒，第二次等2秒，第三次4秒，依此类推，最多不超过30秒或60秒；同时在每次等待时间上加一个0~1000毫秒的随机抖动，让所有客户端的重连时间不至于整齐划一。这段代码我在多种语言里都写过，核心逻辑如下，用伪代码表示：

text复制delay = min(base * 2^attempt, maxDelay) + random(0, 1000)

指数退避的还有一个容易被忽视的细节：订阅请求的幂等性。重连成功之后，客户端做的事情和首次连接时一样，需要重新发送订阅列表。如果订阅列表很大，或者重连频繁，订阅消息本身也会成为服务器压力的一部分。所以客户端在重连后，最好是等连接建立稳了再发送订阅请求，并且订阅请求和重连逻辑要能去重，不要出现“同一个品种订阅了两遍”的情况。

5.4 一套可以落地的连接监控方案

压测到后期，我最大的体会是：比“能扛多少”更重要的问题是“怎么知道它快扛不住了”。

监控不能只看连接是否断开，因为很多问题都是在连接断开之前就开始悄悄发酵的。我自己做了一套轻量级的监控方案，采集以下四个指标：

• 心跳延迟：记录每次发送Ping到收到Pong之间的耗时。正常情况下应该是个位数毫秒，如果超过500毫秒，就说明链路有拥塞。
• 消息消费积压数：客户端缓冲区里待处理的消息数量。超过设定阈值时报警，这是预测崩溃最有效的指标。
• 单位时间下单速度与实际处理速度：两者之差就代表了积压速度，可以计算出多少秒之后会触发溢出。
• CPU和内存占用率：重点看GC/内存回收的频率，内存曲线持续上涨比瞬时峰值更值得警惕。

这四个指标用Prometheus加Grafana就能实现一套完整的监控面板。我在实际使用后，数据总能提前十分钟预警潜在的危险，比看到“连接被服务器断开”的告警再急着排查要舒服太多。

6. 关于“到底选单连接还是多连接”的实战体会

文章写到这里，肯定还有人想问：那我到底应该怎么选？

我的个人做法比较务实：如果业务只需要28个主流货币对，而且对稳定性要求高，我会用一个连接，但会把连接做成双活冗余，同时挂两个行情服务，主连接断了立刻切换到备用，切换过程中用指数退避和本地缓存顶住。如果业务需要覆盖100个以上货币对，或者需要同时处理外汇、黄金、原油等多类品种，我会拆成3~4个连接，按品种类型和消息频率分开订阅，每个连接各管一摊，出的问题彼此隔离。

另外还有一点很想说：做这类压测的时候，不要只在安静的测试环境里跑，一定要在真实行情的活跃时段跑一遍。我见过很多系统在下午测试时一切正常，一到晚上美国数据发布，大批量连接瞬间崩掉。行情API的性能和普通WebSocket应用最大的不同，就是高峰流量是突发式的，容量的冗余一定要按峰值来留，而不是按平均值来留。

如果让我最后再给一条经验，那就是：关于容量永远要比最坏情况多留3倍余量。宁可多花点钱买服务器，也不要让交易系统在行情最激烈的时候掉链子。