WebSocket订阅外汇行情，到底能扛多少个货币对？

做外汇量化或者给客户实时报价的朋友，应该都纠结过同一个问题：WebSocket订阅行情，到底能同时扛多少个货币对？说实话，“能扛多少”这个问题看起来简单，但答案藏在API配额、解析速度、带宽、心跳机制好几层里，不是单纯数个数就行。这篇文章我打算把WebSocket订阅外汇行情的整套逻辑拆开，从订阅协议、性能瓶颈、压测方法到常见的529、断流报错，一次性说清楚，帮你找到自己这套系统的真实上限。

无论你是刚接触API的量化新手，还是已经在生产环境里跑行情的老手，这篇文章都值得花十分钟看完。我会用实际项目里踩过的坑和跑过的数据来说明，尽量让你看完就能照着做。

1. 先弄明白：WebSocket订阅外汇行情，你到底在订阅什么

1.1 一次典型的行情订阅请求长什么样

很多人一上来就问“能订阅多少个货币对”，其实连API的订阅模型都没搞清楚。不同行情服务商的WebSocket协议长得完全不一样，我见过比较常见的是两类：一类是“按symbol订阅”，比如发送 {"action":"subscribe","symbols":["EUR/USD","GBP/USD"]}，服务端把订阅成功的列表返回给你，之后这俩货币对的tick就源源不断推过来；另一类是“按频道订阅”，需要你先把货币对映射到频道ID，再订阅频道，比如某家服务商的格式是 {"op":"subscribe","channel":"ticker","symbol":"EURUSD"}。

这里要提醒一句：很多API文档里写的“支持100个货币对”，指的是REST接口可以查询的数量，不等于WebSocket同时订阅的数量。REST是一次性请求响应，服务端临时查一下返回就完了；WebSocket是服务端保持长连接持续推送，每增加一个货币对，意味着服务端的推送线程、缓冲区、序列化负载都增加。所以WebSocket的订阅上限往往比REST查询上限低一个档次，一定要去文档里找WebSocket专用的限制说明。

订阅报文里还会带上一些参数，比如部分服务商要求指定数据粒度（tick、1秒、1分钟K线），有的要求开启快照推送，有的要求带上session token做鉴权。这些参数会影响后续推送的消息内容，订阅时写错字段，服务端可能不会报错，只是不推数据。实操中我建议订阅成功后，把服务端返回的确认消息打印出来，逐字段核对，而不是肉眼猜。

1.2 为什么大家都选WebSocket而不是REST轮询

这其实是个老话题，但放在外汇场景里值得多说两句。外汇行情是所有金融行情里跳动最频繁的类型之一，EUR/USD这种主流直盘在活跃时段每秒能跳动几十次，个别情况下甚至上百次。如果用REST去轮询，假设你每秒请求一次获取20个货币对的报价，每次请求的HTTP头、TLS握手、鉴权参数加一起，光请求开销就吃掉一大截带宽，而且你永远拿不到两次轮询之间的瞬时价格。做高频策略的人对价格延迟极其敏感，REST的几百毫秒延迟在行情剧变时会导致成交价和看到的价格偏差很大。

WebSocket的优势在于一次握手后保持长连接，数据从服务端主动推送到客户端，延迟通常在几十毫秒甚至更低，而且消息体比REST响应精简很多，不需要每次请求都带上冗长的HTTP头。实际项目里我用过同样一家数据源的REST和WebSocket两套接口对比，同样订阅10个货币对，REST每秒轮询的流量是WebSocket推送的十几倍，数据新鲜度还差着一截。所以只要你的业务允许保持长连接，WebSocket基本是最优解。

不过WebSocket也不是没有代价。长连接意味着连接状态需要维护，断线重连、心跳保活、消息时序这些都要自己处理，这恰恰是很多人踩坑的地方。后面我会专门用一节讲断流和重连的问题。

2. 决定“能扛多少货币对”的，其实有四层天花板

2.1 服务端配额：第一道很现实的门槛

第一个天花板来自服务端配额，这个最直接，也最容易被忽略。很多行情API是按订阅连接数和订阅symbol数双重计费的。常见模式是：免费账号只能开1-2条WebSocket连接，每条连接最多订阅10-30个symbol；付费入门档可以开5条连接，每条约100个symbol；更高级别的机构账号才支持上千个symbol的订阅。

这里有个容易踩的坑：很多API服务商的“订阅数量”是按“同一连接内同时订阅的数量”算的，不是按账号总订阅量。比如文档写“单连接最多100个symbol”，你可能会想开10条连接订阅1000个，但服务商可能还有“单账号同时最多10条连接”的限制，两条叠加下来实际上限还是1000，甚至因为连接数超限直接拒绝握手。我建议在写代码之前，先给服务商客服或者文档里的配额表格截图留底，搞清楚三件事：单连接symbol上限、单账号连接数上限、推送频率有没有隐含QPS限制。

除了显式的配额，还要注意隐形的“限流”。有一些数据源虽然写着不限制，但当你一条连接里订了太多交易量小的冷门货币对时，服务端会悄悄降低这些symbol的推送频率，或者在你订阅请求频率过高时返回限流错误。我遇到过最无语的情况是：50个货币对在一条连接里连续订阅，前40个都返回成功，最后一个被静默丢弃，不报错也不推送。排查了半天才发现是服务端对每条订阅消息处理时有符号数上限，多余的被忽略了。这种问题只能靠订阅后主动比对“请求的symbol列表”和“实际收到数据的symbol列表”来发现。

2.2 报文解析与业务处理：第二道真正的瓶颈

服务端配额只是第一层，真正决定你能用多少货币对的，往往是客户端自己的处理能力。行情数据推过来是字符串，你要做JSON解析、字段提取、类型转换、再交给策略模块或者写入数据库。这个过程非常消耗CPU，尤其是Python这类解释型语言。

我做过一个简单的基准测试：用Python的json库解析一条典型的行情tick消息（大约200字节），单核大概能解析2-4万条每秒，看起来很多对吧？但问题是行情推送是突发性的，比如重大数据公布时，几十个货币对可能在同一秒集中推送几千条消息，瞬时QPS会冲到很高。如果你的解析和业务处理是串行的，消息积压就开始出现了，延迟从几十毫秒涨到几百毫秒，最后CPU被打满，连接被系统判定为不健康，甚至触发断连。

这里我强烈建议做两件事。第一，解析和业务处理解耦，订阅回调里只做最少的解析工作，把解析后的数据丢进消息队列或者asyncio.Queue，由独立的消费协程去处理，避免行情数据直接阻塞在业务逻辑上。第二，评估要不要跳过JSON解析，很多服务商支持二进制协议，比如Google Protobuf或者MessagePack，性能能提升一个数量级，但代价是要自己维护schema。如果服务商只提供JSON，你可以考虑用orjson这类高性能库替代标准库，实测解析速度能提升2-5倍。

还有一个老生常谈但很关键的细节：不要在解析回调里写日志、调外部API、执行任何可能阻塞的操作。我之前刚写行情采集模块时，习惯在每个tick里打一条日志，行情密集时发现CPU占用率直接飙到80%以上，去掉日志后降到20%。日志和IO都是隐藏的吞性能大户，处理高频行情时尤其明显。

2.3 网络带宽：算一笔账就明白了

很多人在估算“能扛多少货币对”时压根没算带宽，结果系统跑到某个数量级突然开始丢包或者延迟飙升，一查才发现是带宽打满了。这里我给一个简单的估算方法。先看单条消息的平均大小，假设平均300字节（不同服务商差异很大，有些包含几十个字段的完整报价消息能到800字节以上）。再看每条连接的推送频率，主流货币对在活跃时段大概每秒几十个tick，冷门货币对可能几秒才一个tick。假设你订阅100个货币对，其中20个是活跃主流货币对，平均每个每秒推送30条tick，80个冷门货币对平均每个每秒推送2条tick，那么每秒消息总量大约是 20×30 + 80×2 = 760 条，流量大约 760×300 = 228000 字节每秒，约1.8Mbps。

这个量级单条带宽其实还能扛，但如果你的VPS出口带宽是10Mbps，业务上还要跑REST请求、网页前端、其他服务的流量，那1.8Mbps的行情推送就占了百分之二十了。更麻烦的是瞬时峰值，非农、利率决议这种时刻，主流货币对的推送频率可能瞬间翻好几倍，如果带宽余量不够，TCP缓冲区满了以后数据开始丢弃，表现出来就是行情延迟突然拉满。我的经验是：给行情订阅预留的带宽至少要是平均值的三到五倍，宁可多买点带宽，也别在关键时刻掉链子。

2.4 心跳与连接稳定性：最容易被忽略的隐形天花板

最后一个容易被忽略的限制是心跳机制。WebSocket连接长时间没有数据交互，中间的网络设备（尤其是NAT网关、负载均衡器）可能会把空闲连接回收掉。所以大多数服务商都会要求客户端定期发送心跳帧，比如每30秒发一次ping，服务端回pong。问题在于，这种心跳机制对外汇行情来说有个比较尴尬的情况：凌晨时段市场流动性差，很多冷门货币对可能好几分钟才有一条tick，如果你只依赖行情数据本身来判断连接是否存活，连接很可能会被中间设备掐断。

我踩过比较惨的坑是：订阅了80多个货币对，凌晨三点多有一个货币对短时间没有推送，连接被服务端判定超时主动断开。系统重连之后需要重新订阅，但重连逻辑没写全，导致某些symbol漏订阅了，直到早上才发现数据缺了一部分。这个问题不是“能扛多少货币对”直接相关的，但它决定了你扛起来之后能不能稳定地扛住。后面第五章我会专门讲心跳和重连的配置技巧，这里先记住一个结论：连接数、订阅数、心跳频率三者是联动的，判断系统的真实容量时缺一不可。

3. 实测：给订阅通道做一次完整的体检

3.1 压测前要准备好的环境

理论算了一堆，最后还是得实测。但在跑压测之前，有四个环境问题一定要先处理好，否则数据没参考价值。

第一，用一台干净的机器。别在本地笔记本上测，你的WiFi、后台软件、散热降频都会干扰结果。我一般用一台和业务部署环境同规格的云服务器，网速、CPU型号尽量和生产一致。第二，先做基线测试。在还没订阅行情的时候，记录机器的空闲CPU、内存、带宽占用，压测结束后减去基线数据，才是行情通道真实的消耗。第三，准备好监控工具。至少要有top查看CPU内存，nload或iftop查看带宽，ss -s查看TCP连接状态。如果想精细一点，用tcpdump抓包分析实际收到的数据量和重传率。第四，确认测试账号的配额上限。如果服务商文档说单连接最多50个symbol，你就没必要测200个的情况，那不是通道不行，是账号不够格。先确认配额再设计压测档位，效率高很多。

3.2 从10个货币对开始逐步加压：脚本与参数

我的做法是从10个货币对开始，每次翻倍加压，每档至少跑5分钟，记录稳定期的数据。这里给一个基于websockets库的Python压测脚本雏形，你可以根据自己用的服务商协议改一下：

python复制import asyncio
import json
import time
import orjson

async def subscribe_and_collect(ws_url, symbols, duration=300):
    received = 0
    last_ts = time.time()
    latency_sum = 0.0

    async with websockets.connect(ws_url, ping_interval=30) as ws:
        # 订阅请求，实际字段以服务商文档为准
        await ws.send(json.dumps({
            "action": "subscribe",
            "symbols": symbols,
            "data_type": "tick"
        }))
        # 等待订阅确认并读取初始快照
        ack = await asyncio.wait_for(ws.recv(), timeout=10)
        print(f"订阅确认: {ack}")

        async def collect():
            nonlocal received, latency_sum
            while True:
                msg = await ws.recv()
                # 用 orjson 解析，只记录条数和耗时
                t0 = time.perf_counter()
                data = orjson.loads(msg)
                latency_sum += time.perf_counter() - t0
                received += 1

        task = asyncio.create_task(collect())
        await asyncio.sleep(duration)
        task.cancel()
        
        avg_latency = latency_sum / received if received else 0
        print(f"symbols={len(symbols)} received={received} "
              f"avg_parse_ms={avg_latency*1000:.3f}")

async def main():
    ws_url = "wss://your-provider.example.com/ws"
    # 从主流货币对列表开始，每档递增
    symbols = ["EUR/USD", "GBP/USD", "USD/JPY"]  # 实际按服务商格式
    await subscribe_and_collect(ws_url, symbols)

asyncio.run(main())

脚本里的核心指标有三个：收到消息总数、解析耗时、有没有出现积压。如果5分钟内received数量稳定，解析耗时没有持续上涨，说明这一档还扛得住；如果received数量在某一档开始明显下降，或者消息积压导致延迟越来越大，说明到瓶颈了。

我通常会记录每一档的CPU占用率。当CPU占用率超过70%时，即使当前档位还能接收，我也不会继续往上加压。预留30%的CPU余量是为了给突发行情、重连恢复、其他业务留出喘息空间，行情峰值数据进来时才不会直接把进程拖垮。这个经验值来自我在实盘环境的教训，之前就是压测时把CPU跑到90%，上线后行情一波动，进程直接卡死，导致报价断档。

3.3 实测数据怎么看：一张表说清楚

压测跑完之后，我习惯把结果整理成一张表，方便对比不同档位的趋势。下面这张表是我在某次测试中拿到的真实数据形态，你可以参考这个格式记录自己的结果：

注意观察两个拐点：第一，CPU占用率从63%跳到84%时，解析延迟从0.31ms涨到0.55ms，接近翻倍，说明CPU接近饱和，线程切换开始拖慢解析；第二，出现丢包时说明服务端或客户端已经处理不过来，这一档就是实际上限的“危险区”。在真实环境里，我一般会把“CPU占用率低于70%且无丢包”的最大档位作为生产环境配置的参考值。比如上表里100个货币对能满足这个条件，150个不行，那生产环境就按100个以内来设计订阅策略。

这里再说一个很多人忽略的细节：压测时的市场状态要和你的生产时段一致。白天亚洲盘和欧洲盘重叠时段，行情跳动频率剧烈，测试结果才有代表性；如果你半夜测试，tick频率低，得到的“最大支持数量”会虚高。我自己固定在北京时间晚上8点到10点、欧美盘重叠时段测试，这个时段是外汇市场流动性最充沛的窗口，测出来的数据能覆盖绝大多数生产场景。

4. 常见报错排查实录：529、断流、连接超时

4.1 api error: 529 overloaded 到底该怎么处理

最近很多人在社区里反馈遇到 api error: 529 overloaded. this is a server-side issue, usually temporary 这个报错，其实不止是天气API和星火API会有，外汇行情API同样可能返回类似的状态码。529的核心含义是：服务端过载了，这是服务端问题，且通常是暂时性的。

很多人的第一反应是加并发、多开连接、疯狂重试，希望用客户端数量绕开服务端瓶颈。这个思路在529场景下完全行不通，甚至会雪上加霜。服务端返回529是因为它的负载已经很高，你重试得越猛，服务端压力越大，恢复越慢。正确处理方式是按指数退避策略重试，每次重试的间隔逐渐拉长，比如第一次3秒、第二次6秒、第三次12秒，直到最大间隔。同时给重试加一个随机抖动（jitter），防止多个客户端同时重试造成“惊群效应”，服务端刚缓过来又被一波重试打趴下。

我之前遇到过一次529持续了将近十分钟，期间我维护的行情进程反复重连，把服务端当成了自己可以无限压榨的资源。后来改成退避重试并加了告警通知，服务端恢复后连接就正常拉起来了，没有再踩二次过载的坑。这里也要说一句：529出现时先想想自己的订阅量是不是超配额了，如果长期稳定运行突然出现529，多半是服务端高峰期负载高，但如果刚加了一大批货币对就出现529，那更可能是你的订阅量触发了服务端的保护机制。

4.2 stream disconnected / websocket closed by server 的常见原因

另一个高频报错是 stream disconnected before completion: websocket closed by server before res...。看到这个报错，先别急着怀疑自己代码写错了，它其实有很多种成因，我按出现频率从高到低排一下。

最常见的原因是订阅过多触发了服务端的保护性断开。有些服务商不会提前告诉你“订阅超限”，而是在你确认订阅之后，服务端检测到单连接的消息推送量超过阈值，直接掐断连接。其次常见的是心跳超时，客户端长时间不发送心跳或者没有处理服务端的ping，服务端判定连接不活跃，主动关闭。第三个原因是订阅了不支持或者不存在的symbol，服务端在推送过程中遇到某个符号的数据源异常，可能直接把整个连接断开。

处理这类断流问题，我建议三管齐下。第一，记录断流前的最后一条消息内容，很多服务商会先推送一条错误码或者warning，再断开连接，这条消息是排查的重要线索。第二，解析服务端返回的close frame中的状态码，WebSocket协议里1000是正常关闭，1006是异常断开，4000以上通常是业务错误码，文档里会有对应说明。第三，建立告警机制，把“连接断开”和“自动重连成功”“重连失败”分别告警，别把断线重连这种信息淹没在日志里，导致长时间不知道行情已经中断。

4.3 心跳超时与自动重连的正确姿势

自动重连不是随便 while True: connect() 就完事，正确姿势要考虑三件事：退避策略、订阅恢复、状态清理。

退避策略刚才已经说了，指数退避加抖动是必须的。这里再补充一点：重连成功后先做一个最小化订阅测试，比如先订阅一个symbol，确认连接正常、能收到数据，再批量订阅之前的全部symbol。直接一次性订阅上百个symbol如果出了问题，排查起来成本很高，先小后大虽然慢几秒，但稳妥很多。

订阅恢复的逻辑也很容易写漏。重连后连接是全新的，服务端不会记得你之前订阅过什么，必须重新发送订阅请求。很多人重连后只建立了连接，没有重新订阅，导致日志显示“已连接”但实际一条行情都收不到。我建议把“当前应订阅的symbol列表”维护在配置中心或内存中，重连后统一从配置里重新订阅，老连接已经订阅的symbol列表要清空重置，避免新旧连接状态混乱。

还有一点容易被忽视：连接断开期间行情是缺失的，是否需要补偿。如果应用场景是实时展示报价，断线期间的缺失行情直接跳过，等重连后拿最新价就行；但如果是策略计算依赖连续tick序列，断线重连后需要向服务端请求一次历史快照或者补拉数据，否则策略计算基于不完整的数据，容易出现误报。这个取舍和业务强相关，一定要提前想清楚，别等生产环境断线了才研究。

5. 把订阅通道整稳的几条实操经验

5.1 一条连接还是多条连接：按业务场景拆开

“能扛多少货币对”这个问题，优化空间其实很大。很多人默认把要订阅的所有货币对塞进一条WebSocket连接里，管理最简单，但缺点很明显：一旦连接断开，所有订阅全部失效，重连成本极高；而且单连接的消息量上限是固定的，不如多连接横向扩容。

我的做法是按业务场景拆成多条连接。比如，一条连接专门订阅主流直盘，给实时交易系统用；另一条连接订阅交叉盘和冷门货币对，给行情展示大屏用。这样即便展示通道出了故障，交易系统的连接还能正常工作，两个业务互不拖累。拆分还有另一个好处：不同连接可以设置不同的心跳频率和重连策略，重要的连接配置得更激进，次要的连接放低优先级，资源分配更有针对性。

多条连接的代价是客户端代码复杂度上升，要维护多个连接实例，还要小心别在多个连接的订阅请求里重复订阅同一个symbol，否则服务端可能按重复订阅计费，或者推送两条一模一样的行情消息，造成数据重复。

5.2 消息降频与关键报价优先

如果实测下来你的机器确实扛不住那么多货币对，除了升级配置，还有两个性价比很高的优化方向：消息降频和关键报价优先。

消息降频的意思是，对非核心的货币对，不需要每个tick都处理。你可以订阅原始tick流进来之后，在客户端做一次时间窗口聚合，比如5秒合成一个OHLC，只有价格变化超过阈值时才触发业务处理。这样冷门货币对虽然订阅了，但消耗的资源非常有限，可以把CPU和带宽节省出来给真正需要细粒度数据的核心货币对。

关键报价优先则是按重要性分流。比如你的策略主要跑EUR/USD和GBP/USD，那就保证这两个货币对的数据链路最短、延迟最低；其他货币对可以走一个低优先级的队列，处理不过来时先丢弃降级，不拖累核心数据。我通常会给不同货币对打上不同的优先级标签，消息进入队列后按优先级消费，高优先级的tick永不积压，低优先级的tick即使丢了也不影响主业务。

5.3 避坑清单：我踩过的那些坑

最后整理一份避坑清单，都是我在实际项目里踩过或看别人踩过的，建议收藏备用。

• 订阅后一定要验证是否真的收到数据。很多服务商订阅成功和推送数据是异步的，订阅响应返回了不代表数据已经推过来。订阅后等几秒，统计实际收到数据的symbol集合，和订阅请求的symbol集合做对比，多了少了都要查原因。
• 不要在解析回调里做数据库写入。行情推送的写入频率非常高，同步写入数据库会卡住解析线程，导致消息积压。正确做法是把数据先放进内存缓冲，批量攒够50条或者100条再批量写入，极大降低数据库压力和IO开销。
• 把行情进程和策略进程分开部署。行情采集进程负责稳定接收和转发数据，策略进程只订阅整理好的数据流。这样行情进程崩溃了，策略进程不会跟着一起挂；策略要升级重启，也不会打断行情接收。
• 重连恢复后主动比对数据连续性。我一般会在重连后记录最后一条数据的seq（如果服务商支持）或者时间戳，重连后收到的第一条数据如果存在明显跳变，马上触发告警，说明中间丢了数据或者漏订阅了。
• 测试环境的服务商配额和生产环境一致。很多人在测试环境用免费账号联调，生产环境换高配额账号，结果上线的第一天突然出现限流或者报错，就是因为两套环境的配额完全不同。上线前最后一天，务必在高配额账号下再完整跑一次压测。

还有一个经验值：订阅数量越接近上限，稳定性越差。如果用100个货币对能稳定运行，但账户允许你订200个，别贪多。行情源的服务器也不是无限容量，订阅数量远超平均值时，你拿到的服务质量和连接稳定性都可能下降。与其顶着上限跑，不如留30%的余量换一个稳定不闹心的行情链路。

我自己在实际项目里摸索下来的体会是：WebSocket订阅外汇行情的“能扛多少”，最终不是由API文档里那个数字决定的，而是由你的机器、代码、连接策略和容灾设计共同决定的。先把订阅模型搞清楚，再按带宽、CPU、解析延迟四个维度做一次体检，你就能得出自己这套系统最真实的容量上限。最后再分享一个小技巧：压测数据一定要保留下来，每次升级配置、调整订阅策略之后重新跑一遍，拿新旧数据对比，比任何猜测都靠谱。这个习惯帮我避免了好几次“拍脑袋加订阅数导致线上翻车”的尴尬。