维拉特·科利（Virat Kohli）走上球场的瞬间，流量不是爬坡，是垂直跳崖。5,000人在线，三分钟后12万，每个人都等着下一球的推送通知。Xenotix Labs的第一版实时系统，就是被这条曲线干掉的。

第一版怎么死的

第一版架构简单直接：单Node.js进程跑socket.io，每个连上的客户端订阅所有直播比赛。2,000并发时跑得漂亮，15,000时开始丢心跳，40,000时事件循环延迟突破3秒，重连风暴让情况雪上加霜。

复盘发现三条铁律：单Node进程的天花板在2万到4万socket之间，看事件循环在忙什么；单进程广播是O(N)复杂度，一场热门比赛就能拖垮整个循环；重连风暴真实存在——网关重启后，断线客户端会在约2秒内集体重连，等于自己给自己发动DDoS。

重建的三条原则

第一，WebSocket网关节点做"傻" Stateless——只持连接、转发消息，零业务逻辑。第二，Redis pub/sub当总线——每个网关订阅以match_id为键的频道，比分更新只发布一次，各网关向自己持有的连接扇出。第三，ALB上开Sticky Session——客户端凭cookie重连同一网关，连接状态不乱跳。

数据流：比分提供方 → 接入worker → Redis PUB match:123 → N个网关SUB match:123 → WS推送给客户端。扩容变成水平游戏：加网关节点，Redis负责扇出。单Redis集群每秒处理数十万pub/sub消息。

最后一个细节

每条WebSocket消息都是增量，而非全量刷新。一球投出，推的是{over: 14.3, runs: 4, batsman: "Kohli"}，不是整张记分牌。原因很现实：12万连接时，200字节的增量对比4KB的快照，带宽差距是20倍。