实时比分系统从轮询到长连接的迁移经验：电竞数据推送架构演进实录
电竞比分直播对数据实时性的要求远高于传统体育资讯。一场团战打完，比分可能在两三秒内发生变化，用户刷新页面时看到的如果还是上一波的数据，体验就会大打折扣。早期很多电竞数据平台采用轮询方式获取比分，实现简单、兼容性好，但很快就遇到了瓶颈。
轮询的核心问题在于它把实时性的主动权交给了客户端。客户端每隔固定时间发一次请求，服务端返回当前比分。如果间隔设得长，比分更新就会有明显延迟；如果间隔设得短，大量请求返回的是没有变化的数据，服务端连接数和带宽被白白消耗。在多场赛事同时进行的高峰时段，这种浪费会被成倍放大。更麻烦的是，轮询模式下客户端数量增长和服务端压力是线性关系，扩容成本很高。
长轮询是第一个被认真考虑的替代方案。客户端发起请求后，服务端不立即返回，而是等到比分真正发生变化或者超时后才响应。这样减少了无效请求的数量，实时性也比短轮询好。但长轮询本质上仍然是请求-响应模型，每次比分变化后连接就会关闭，客户端需要重新发起下一次请求。在高频比分更新的场景下，连接的建立和断开反而成了新的开销。而且服务端需要为每个挂起的请求维持上下文，并发量上去之后，内存和文件描述符的消耗并不比短轮询乐观多少。
真正让实时比分系统发生质变的是WebSocket长连接。客户端与服务端建立一条持久连接，比分变化时服务端主动推送，不需要客户端反复询问。这条路径在延迟、带宽利用率和用户体验上都明显优于轮询系列方案。但迁移过程并不是换一个协议那么简单，实际落地时会遇到一系列需要仔细处理的问题。
连接保活是第一个绕不开的环节。WebSocket连接可能因为网络切换、代理超时、服务端重启等原因无声无息地断开，客户端却不一定能立刻感知。常见的做法是客户端定时发送心跳帧，服务端在约定时间内没有收到心跳就判定连接失效并释放资源。心跳间隔需要权衡：太短会增加不必要的流量和电量消耗，太长则断线发现不及时。在移动端浏览器和客户端并存的场景下，还需要考虑不同网络环境下的差异化策略。
断线重连是第二个关键问题。用户在地铁里切换基站、笔记本合盖再打开，连接都可能中断。客户端需要有一套完整的重连机制，包括重连间隔的退避策略、重连次数的上限控制、以及重连成功后的状态同步。退避策略很重要，如果所有断线客户端都立即重连，服务端会在瞬间承受巨大冲击。指数退避配合随机抖动是常用的做法，可以有效分散重连请求。重连成功后，客户端不能假设自己还持有最新的比分数据，应该主动请求一次全量快照，或者携带最后收到的消息序列号让服务端续推。
消息有序性和幂等处理是比分数据准确性的保障。比分变化的消息在网络传输中可能乱序到达，也可能因为重连而重复推送。如果客户端不做校验，就可能出现比分回退或者错误累加的情况。实践中通常会在消息体中附带递增的序列号或版本号，客户端按序比对，发现跳号就触发一次全量拉取来补齐。对于同一场比赛的比分变更，服务端在推送时应该保证串行发出，避免多线程并发写入导致消息顺序错乱。
降级策略是迁移过程中容易被忽视但必不可少的一环。长连接虽然好，但它依赖的环节更多，出故障的概率也相应增加。当WebSocket网关负载过高、或者客户端所在网络环境对长连接不友好时，系统需要有能力回退到短轮询模式。降级不是简单地关掉长连接，而是要设计好触发条件、切换过程和恢复机制。客户端在多次重连失败后自动切换到轮询，以较低频率获取比分，保证用户至少能看到数据。服务端在压力过大时也可以主动断开部分非活跃连接，引导它们走轮询通道。恢复时同样要控制节奏，避免大量客户端同时回切长连接造成二次冲击。
数据推送的粒度也值得仔细设计。早期的做法是比分有任何变化就推送整场比赛的全量数据，消息体大、冗余多。更合理的做法是按变更字段做增量推送，只发送变化的部分，客户端在本地合并。对于电竞赛事中的小局比分、经济差、推塔数等多项数据，可以按重要程度分级推送，关键比分变化优先保证送达，次要数据可以合并或降低推送频率。
在服务端架构上，长连接网关通常需要独立部署，与业务逻辑解耦。网关负责维护连接、处理心跳、管理订阅关系，业务模块只负责在数据变化时向网关投递消息。这样做的好处是网关可以独立扩容，业务模块的变更不会影响连接稳定性。订阅关系也需要精细化管理，用户可能同时关注多场比赛，网关要能按赛事维度做消息分发，避免无关消息推送给不关心的用户。
监控和可观测性在迁移后变得更重要。轮询模式下服务端压力直观体现在QPS上，长连接模式下则需要关注在线连接数、心跳超时率、重连频率、消息推送延迟等指标。这些指标能帮助判断系统是否健康，也能在出现问题时快速定位是网络层、网关层还是业务层的原因。
从轮询到长连接的迁移，本质上是从拉模式向推模式的转变。这个转变带来的不仅是技术方案的升级，还有思维方式的变化：服务端需要主动管理连接状态，客户端需要处理更多异常分支，运维需要关注更多维度的指标。对于正在规划或正在执行迁移的团队，建议先在部分赛事或部分用户上做灰度验证，观察连接稳定性、消息延迟和降级触发情况，确认无误后再逐步扩大范围。迁移不是一蹴而就的事情，分阶段推进、保留回退能力，比追求一步到位更稳妥。