北京
晚上7点，流量精准冲上波峰；凌晨3点，用户散去，曲线跌入低谷。这是Netflix再熟悉不过的日常节奏。可一旦热门剧集回归，或直播赛事启动，那条平滑的曲线就会被瞬间撕裂——巨大的访问洪峰毫无预兆地砸过来。团队知道它会发生，但永远猜不准会有多少人同时点下播放键。
问题摆在了平台工程师本杰明和播放后端负责人阿尼鲁德的桌上。本杰明回想起快两年前（也就是2024年）的乐观心态：好剧扎堆回归，平台工程师的日子似乎可以躺平。但阿尼鲁德掌管的Play API——用户每次点击播放都会调用的关键服务——时刻站在风暴眼。“我们面对的不是恶意攻击，全是实打实的正常流量。”阿尼鲁德说。
为什么不能直接扩容？他们不是没试过。反应式扩容盯着CPU利用率，等指标触发再拉起实例，几分钟的延迟在云环境中足以让服务被冲垮。主动扩容倒是可以按“所有用户都到场”的极端需求提前备足资源，但成本高得肉疼，而且云厂商或数据中心不一定有那么多闲置容量。更头疼的是“惊群效应”：直播时大量用户同时遭遇卡顿，齐刷刷点击刷新，形成的请求风暴完全背离日常模型，容量规划彻底失效。
在扩容的性价比和天花板都显露之后，Netflix团队把目光转向了另一条路：负载削减。不是硬扛所有请求，而是在必要时有选择地“减负”，让核心服务活下来。这就像限流，但拆得更细——哪些请求可以降级、延迟处理，哪些必须死守，一切要以服务的优先级重新排序。
这个思路后来被他们打磨成“优先化负载削减”。在真正铺开到全量集群之前，团队要啃下三块硬骨头：理论推演——没有负载削减时集群会怎么崩；第一版粗糙实现；然后是调参、验证与大规模铺开。每一步都在回答同一个问题：当汹涌的真实流量再次扑来时，保障核心播放体验的底线能不能守住。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
