3200万人同时看球，工程师却按7500万备战

2023年那场板球决赛，峰值涌进来3200万并发观众。但JioHotstar（当时还叫JioCinema）的工程团队，赛前是按5000万到7500万的容量去做压测的。

Ashutosh Agrawal在P99 CONF上复盘了这套系统怎么搭、怎么测。他的原话是，这个数字"把团队里每个人都吓得不轻"。吓归吓，多出来的余量就是用来吸收流量尖峰的，让请求不至于堆在一起排队。

他的判断很直接：视频链路上的任何一环都不能挂。其他系统都可以牺牲，但视频交付这条线必须是"黄金路径"。这条线一断，平台对用户的全部承诺就没了。

真正的峰值不在决赛当天

很多人以为压力最大的是比赛开打那一刻。Agrawal说不是。真正的并发高峰出现在第一天——大量新用户，或者过去360天都没登录过的用户，会在头五到十分钟里集中涌进来登录。

登录走的是短信加验证码。短时间内向全国发出这么多条短信，本身就是一道难题。所以认证这类关键系统要提前扩容，合作方要过严格的压测，延迟达不到SLA的，活动期间直接切掉。哪家合作方延迟一掉，流量立刻按层级转到下一家。

赛前还有一份200项的系统检查清单。数据库跑的是不是最新版本、比赛时段有没有撞上维护窗口、各家合作方的关键依赖和冗余配置、负载均衡到服务、服务到应用服务器、应用服务器到数据库、一路到CDN的超时设置，全在清单里。

清单上大部分条目都是踩坑换来的。有一次某个服务没配好keep-alive超时，高峰时它不是在复用连接而是在丢弃连接，负载均衡器扛不住请求量直接崩了。这件事后来就成了下一赛季的检查项。

清单还逼着每个服务负责人回答极端问题：如果所有短信合作方全挂了，系统怎么办？不能把用户锁在门外，得让人进来，哪怕是不带认证的方式。这可能要回头找产品重新设计，比如给个五到十分钟的免登录观看窗口，或者发临时令牌、把认证往后推。

三层测试，最后一层最关键

测试分三层。第一层是纵向测试，先单独压每个系统和服务，确认它自己能扩；再逐个压合作方，短信、邮件、广告，凡是接进关键路径或周边路径的都要过一遍。

第二层是多系统联合压测。Agrawal的说法是，一个服务单独压的时候扩得很漂亮，一加上依赖就原形毕露。比如测播放，就得把内容系统、分析系统、CDN负载均衡系统拉成一个集群一起压。

第三层是模拟真实用户行为，在App或网站上跑，看会牵动哪些关联系统。这一层帮他揪出过关键问题：内容系统会被多个地方调用——列表页、详情页、取播放元数据的地方。哪个团队忘了算这种扇入，预算和扩容的问题只有在全链路模拟里才会暴露。

延迟预算：内部系统10到15毫秒

他们内部的规矩是：纯自研、不碰第三方的系统，做一次简单查找加下游响应，服务端预算大约10到15毫秒，不算网络。情况复杂些，比如多次数据库调用或要调第三方，放宽到40到50毫秒。关键路径上任何一环超过50毫秒，就开始考虑能不能改成异步。

把客户端、网络、CDN回源、最后一公里都算进去，用户实际感受到的是60到100毫秒。

预算最紧的是那个API——用户点下视频卡片到视频真正播起来之间的那一步。这里一失败，用户就反复重试，或者关掉App再打开，反而把API压得更狠。这个接口很难缓存，每次调用都要实时跑CDN负载均衡和认证检查。哪怕绕不开第三方调用，也得卡在5到10毫秒的熔断预算内，快速失败再恢复，好过干等着一个"正确"的结果。

这套预算的用处是拿来质问服务负责人：还能优化什么、怎么减轻线上负载、还能多缓存多少、多少能提前准备好。登录当然没法缓存，但用户一落到首页，页面能缓存的尽量缓存。个性化会让事情变麻烦，所以页面是按块、按组件分开缓存的，布局配置和内容各缓各的，拼起来页面响应依然快。

给备战大促的人三条建议

Agrawal最后给了三条，适用于黑五这类高不确定性场景。

1. 先把原则定对。跟管理层和团队在全公司层面达成优先级共识，这个共识决定了活动前、活动中、活动后的所有决策。原则打架，决策就会堵在一个瓶颈上。
2. 去挑战你的系统，别将就。别觉得100毫秒的响应时间就挺好。算力和技术都进步这么多了，服务端延迟没理由停在几百毫秒——客户端延迟是另一回事，服务端延迟基本在你自己手里。
3. 找出关键路径并确保它足够硬。这事真不容易，不是看看高层系统就行。比如发分析数据的同步调用，它就不该是同步的，压根不该出现在关键路径上。不是真正P1、P2级别的依赖，都不该待在那条同步链路上。为此可能要拒绝一些需求，或者被迫重构一部分，但这是最重要的一件事。