iGaming平台扩容：应对1000万并发用户的经验

欧冠决赛，20:59。娱乐场平台显示 120 万并发会话。到 21:01 开球时，这个数字冲到 1040 万。

在那两分钟窗口里，每一张卡住的投注单、每一笔失败的存款、每一次陈旧的赔率显示，都会把玩家推向竞争对手的体育博彩引擎。

按峰值负载做设计，而不是当作例外

按平均负载设计、峰值时再被动应对，必然在监测发现问题之前就出现服务降级。应把峰值负载作为设计基线。

这需要理解iGaming行业特有的流量模式：

• 欧冠决赛开球后60秒内会产生平常8-12倍的流量——这一爬升可以精确到分钟预测
• 爆款娱乐场游戏活动的流量爬升无法预测——推送触达500万台设备后的几小时内，玩家行为就会改变
• 真人荷官游戏的负载不是瞬时冲高，而是持续4-6小时维持在高位，需要的是持续吞吐能力而非突发容量
• 与体育赛事挂钩的免费旋转活动会造成跨产品的负载尖峰：体育博彩引擎和在线赌场游戏争抢同一套基础设施

把投注路径与所有下游系统解耦

当1000万用户同时涌入平台，关键要求是：即使结算、分析或忠诚度体系变慢，投注下单仍然要快。

基于消息队列的事件驱动架构可以干净地处理这一点：

• 投注写入持久化队列，50ms 以内返回确认——玩家侧体验保持流畅
• 结算、玩家管理分析和欺诈检测异步消费该队列
• 存取款的支付处理运行在独立的基础设施上，永远不会和下注争抢资源
• 忠诚度计划和免费旋转的触发逻辑消费同一条事件流，不会阻塞投注路径

这套架构把一致性保证写得明确：投注受理和支付系统需要同步确认，其余部分按最终一致性运行。

按iGaming的读写模式设计数据库

下注是写操作，查看赔率是读操作，展示排行榜也是读操作。三者的负载特征不同，一致性要求也不同。

CQRS——读写模型分离——让只读副本独立扩容。赔率查询、游戏历史和玩家偏好由副本提供，不影响投注和结算的事务完整性。

其余部分由三层缓存策略承接：

• 热数据在应用层驻留内存——当前赔率、玩家余额、有效免费旋转次数——提供亚毫秒级读取
• 服务层用Redis保存跨实例共享状态——会话数据、实时排行榜——在1-2ms内完成
• 边缘 CDN 承载静态资源、游戏商缩略图和预渲染的娱乐场游戏大厅

每隔几秒更新一次的赔率数据，不需要每次请求都打到主库，缓存起来即可。

在赛事直播期间监控玩家体验，而不只是服务器健康状况

如果投注下单延迟超过500ms，服务器CPU占用只有40%也说明不了任何问题。要监控玩家实际感受到的指标：

• 跨服务的分布式追踪：跟踪一笔投注从点击到确认经过的每一个微服务
• 在p50、p95和p99上做实时延迟分位跟踪——平均值会掩盖引发玩家投诉的尾部延迟
• 对劣化信号自动告警——支付处理延迟增加200ms是警报，不是噪声
• 高峰赛事期间按秒跟踪投注单成功率——从 99.8% 跌到 98.5% 会立即触发排查

识别导致平台在峰值时崩溃的四种模式

在重大赛事中挂掉的平台有一些共同特征：

• 本应解耦的服务之间存在同步依赖——一次缓慢的欺诈检测会阻塞投注下单
• 从未按真实峰值量做过压测的缓存——1000 万会话同时请求同一盘口时出现缓存击穿
• 在 1 倍负载下正常、到 10 倍负载因锁竞争或连接池耗尽而崩溃的数据库设计
• 把存取款排在注单结算之后的支付系统，会在充值流程中造成玩家可感知的延迟

撑得住的平台都在做不起眼的工作：按真实峰值做压测、用混沌工程验证降级确实生效、写好让值班工程师照着执行的操作手册，而不是临场发挥。

把可扩展性转化为玩家留存

玩家留存取决于信任。重大赛事期间一次糟糕的游戏体验（注单卡死、充值失败、屏幕上赔率过期），会把玩家永久推向竞争对手。

在线博彩市场奖励那些让人感觉不到存在的平台。把可扩展性当作持续工程纪律、并在每次大型赛事前用接近生产环境的负载测试加以验证的软件开发团队，才能做出体育博彩与在线娱乐场游戏之间的无缝衔接，把玩家留住。

最好的娱乐场平台，是玩家从来不需要去想它的平台。