电竞比分推送的并发处理经验：从消息队列到连接保持

电竞比分推送看起来只是把比分变化告诉订阅者，真正做起来却会遇到一个绕不开的矛盾：数据变更的频率和订阅者的规模会同时放大。一场关注度高的比赛，从BP阶段到关键团战，比分、经济、击杀、推塔等数据可能在很短时间内连续变化；而订阅这些变化的连接数，可能从几千迅速增长到数万甚至更多。写入端和推送端的处理能力并不对等，如果缺少并发处理的设计，轻则推送延迟，重则丢消息、乱序，甚至把长连接服务打挂。

从数据源到订阅者，中间通常要经过采集、清洗、变更识别、分发、推送几个环节。并发压力最集中的位置有两处：一是变更识别后的写入，二是面向大量连接的推送。把这两处拆开看，思路会清晰很多。

消息队列在比分推送中承担的是削峰和缓冲的角色。数据源产生的变更并不均匀，开局和关键节点是密集写入，暂停或间歇期则几乎无写入。如果推送服务直接绑定数据源的输出速率，峰值时来不及消费就会积压，低谷时又大量空闲。引入队列后，写入端只管把变更投递进去，推送端按自己的消费能力拉取，速率不匹配的问题被队列吸收。队列的分区策略也值得考虑，按赛事或按比赛ID分区，可以让同一场比赛的变更保持局部有序，避免全局串行带来的瓶颈。

分区带来有序性，但跨分区的全局顺序仍然无法保证。这时序列号就成了必要的补充。每条比分变更在进入队列前分配一个单调递增的序列号，推送端和接收端都以此判断消息的新旧。接收端发现序列号小于已处理的最后序号，说明是重复或过期消息，直接丢弃；发现序号跳跃，说明中间有缺失，可以短暂等待或主动拉取补齐。序列号机制配合幂等处理，是解决重复推送最直接的办法。幂等意味着同一条变更被处理多次，结果与处理一次相同，这对比分这种状态型数据尤其重要，因为重复应用一次击杀数增加会导致数据错误。

推送乱序是比重复更隐蔽的问题。网络路径不同、消费线程调度不同，都可能让后产生的变更先到达。如果客户端直接按到达顺序渲染，比分可能出现回跳。常见的处理方式是在客户端维护一个短窗口，收到序号不连续的消息时先缓存，等待缺失消息到达后再按序释放。窗口大小需要权衡，太小无法覆盖乱序范围，太大则增加延迟和内存占用。对于比分推送这种对实时性敏感的场景，窗口通常不宜过大，超过阈值就触发一次状态拉取。

长连接的保持是另一个容易被低估的环节。连接建立之后，中间网络设备可能在不通知两端的情况下回收连接，服务端以为连接还在，客户端却已经收不到消息。心跳机制用来探测这种死连接，但心跳间隔需要仔细设定。间隔太短，大量空闲连接会产生可观的无效流量；间隔太长，死连接发现不及时，推送消息发往无效连接会浪费资源。比较稳妥的做法是结合业务消息频率动态调整，在比赛密集时段缩短心跳，在空闲时段适当放宽。

背压是连接层并发处理的关键概念。推送服务面对大量连接时，每条连接的消费速度并不一致。移动网络下的客户端可能因为信号波动而暂时消费缓慢，如果服务端不加区分地向所有连接推送，慢连接会积压消息，占用内存和发送线程。背压策略的核心是感知每条连接的积压程度，当积压超过阈值时，可以选择丢弃部分非关键变更、合并同类变更，或者主动断开连接让客户端重连后拉取快照。相比让慢连接拖垮整体服务，主动降级是更可控的选择。

断线重连后的状态补齐，是很多推送系统在初期容易忽略的部分。长连接断开期间产生的比分变更不会自动补发，客户端重连后如果只等待新消息，会缺失断开期间的比分变化。正确的做法是客户端在重连时上报最后一次收到的序列号或版本号，服务端据此返回增量变更；如果版本过旧或增量过大，则直接返回当前全量快照。增量与全量的切换阈值需要根据数据变更频率和快照大小来设定，目标是在补齐速度和传输开销之间取得平衡。

在实际的比分推送系统中，还有一个容易被忽视的细节是变更合并。同一次事件可能触发多个字段的变化，比如一次团战同时影响击杀数、经济差和胜率预测。如果每个字段变化都单独推送一条消息，接收端会收到大量碎片化更新，既增加网络开销，也增加渲染压力。在推送端做一层短时间窗口的合并，把同一实体的多个字段变更打包成一条消息，可以显著降低推送频率，同时保持语义完整。合并窗口的长度需要谨慎，太长会牺牲实时性，太短则合并效果有限。

从判断一个比分推送系统是否可靠的角度看，可以关注几个信号：峰值时段推送延迟是否明显上升，断线重连后比分是否出现跳变或缺失，同一场比赛的比分在不同客户端上是否一致。这些现象背后往往对应着队列积压、状态补齐缺失或乱序处理不当。理解这些环节的并发处理逻辑，比记住某个具体参数更有价值，因为参数会随业务规模变化，而问题模式相对稳定。