电竞比分推送的并发峰值怎么估算与容量预留

电竞比分推送的并发峰值很少是一条平滑上升的曲线，它更像由赛事事件触发的短时脉冲。开赛前订阅集中、关键击杀或团战结果产生、决胜局与赛后统计回填，都会让消息在短时间内集中扇出。容量预留要解决的问题不是平均有多少人在看，而是峰值到来时连接、消息入口、扇出发送和下游消费是否还能保持可接受的延迟。把赛事日历、订阅关系和推送链路放在同一张图里看，才能避免只加机器却仍然卡在队列或重连上的情况。

从峰值来源看，赛程密度决定基础压力，焦点赛事叠加决定尖峰高度。LOL、DOTA2、CSGO等多个项目同时开赛时，用户可能同时订阅多个比分房间，连接数不一定同比例增长，但消息扇出会明显放大。关键事件包括开赛、比分变化、局间暂停、决胜、赛后数据更新。每次事件不是只产生一条消息，还要考虑多端在线、重复订阅、房间广播、通知重试。用户刷新和断线重连也会叠加。把峰值简单归因于在线人数，容易低估消息层的压力。

容量口径需要拆开看。接入层看长连接数、心跳处理、TLS握手和重连速率；消息入口看写入速率和突发批次；扇出层看每个事件对应的订阅者数量和出口带宽；下游看队列积压和消费延迟；存储看热点比分读写。不同指标不能互相替代。容量规划要先定义服务水平目标，例如高分位端到端延迟、重连成功率、队列恢复时间。没有这些口径，预留多少都缺少判断依据。观测窗口要覆盖峰值形成、峰值持续和峰值回落三个阶段，不能只看一个瞬时点。

估算方法可以从订阅关系出发，估算单个比分事件平均扇出到多少个连接，再按赛事等级和赛程重叠做叠加。历史峰值曲线可用于校准，但要注意赛事组合变化和推送策略变化会改变曲线形状。压测要模拟真实链路：建立长连接、维持心跳、突发消息、批量重连、下游变慢。只压消息发送而不压连接建立，会漏掉接入层瓶颈；只压单机而不压全链路，会漏掉队列和缓存。压测结果应转化为每类资源的容量基线，而不是一个笼统的机器数量。

容量预留不是把总量乘以一个固定系数就结束。接入层要留出重连风暴的余量，消息层要留出突发扇出的余量，队列要留出下游抖动时的缓冲，存储要留出热点比分集中读写的余量。基础容量覆盖常态赛事，弹性容量应对焦点赛事。弹性扩容需要时间，扩容触发指标要选能提前反映压力的信号，例如连接建立速率、消息入口突增、队列增长趋势，而不是等延迟已经恶化。安全垫要按资源类型分层，不能所有资源共用一个比例。

容量再充足也要有降级预案。推送分级是常用手段，把比分变化、关键事件和统计更新分成不同优先级，在压力过高时合并低优先级消息或延后非关键统计。连接保护要限制单连接高频请求，避免重复订阅放大扇出。队列削峰可以用批量消费和背压，但要注意背压不能把压力推回接入层。熔断和限流要能按赛事房间或接口维度生效，避免一个热点影响全部项目。降级预案要演练，否则真正触发时容易误伤核心推送。

容量预留本质是成本与稳定性的平衡。全部按最高峰值准备资源，空闲时浪费明显；只按常态准备，焦点赛事又容易被动。按赛事等级分层预留更现实：高关注赛事保留更充足的安全垫，普通赛事更多依赖弹性。复盘要看峰值曲线、扩容触发时间、延迟分位变化、队列积压恢复时间、降级是否生效。把每轮赛事的容量表现记录下来，形成赛事日历与容量看板的对应关系，后续估算就有可校准的参照。容量管理不是一次性的采购决策，而是随推送策略和赛事结构变化持续调整的过程。