系统设计面试：设计Netflix

「设计Netflix」是一个以读为主的问题，其设计被一个事实所主导：在全球规模上提供视频服务，更多的是一个内容分发与存储的问题，而不是计算问题。面试官希望看到你把控制平面（浏览、搜索、推荐）和数据平面（真正传输字节）分开，并推理如何把以拍字节计的数据交付到离用户更近的地方。

按部就班地推进：先明确需求，再估算规模，设计上传／转码流水线，然后设计通过CDN的播放路径，最后以自适应码率与权衡取舍收尾。下面的讲解遵循这个结构，让你练习的是推理过程，而不是死记一套架构。

1. 明确需求

把功能性需求和非功能性需求分开，并严格限定范围。核心是：用户浏览目录，并能在不同设备和网络条件下流畅地观看视频。

功能性：浏览／搜索目录、开始播放、自适应画质、从上次中断处继续、多设备支持。
非功能性：极高的可用性、低启动延迟、流畅播放（不卡顿）、全球覆盖。
范围之外（要明确说出来）：推荐机器学习的内部实现、计费、DRM的细节——提及它们，然后推后处理。

2. 估算规模

这些数字支撑了以CDN为核心的设计。假设有数亿订阅用户，高峰时有数百万条并发流。单条流就要消耗数Mbps，因此总出口流量可达每秒数十太比特——不可能只靠少数几个中心数据中心来提供服务，这立刻促成了在边缘进行缓存的设计。

3. 内容接入与转码流水线

上传的母版会离线处理，而不是在播放路径上处理。每一部作品都会被转码成多种清晰度版本——多种分辨率和码率——并切分成几秒钟一段的小片段，以支持自适应串流。

转码集群：把母版转换成多种码率下的H.264/H.265/AV1版本；这是一种极易并行化的批处理工作。
切片与打包：把每个清晰度版本切分成短片段，并生成描述它们的清单文件（HLS/DASH）。
把输出结果作为唯一可信来源存入对象存储（类似S3），然后在需求出现之前把热门内容推送到边缘。

4. CDN与播放路径

播放是由边缘节点而不是源站提供服务的。视频片段会被缓存在物理上靠近用户的CDN节点上（Netflix在ISP内部运营自己的Open Connect设备）。客户端先获取清单文件，再从最近的健康边缘节点拉取片段。

控制平面（目录、搜索、用户档案、「继续观看」）是一组独立的无状态API服务，背后有各自的数据库和缓存——它只返回元数据和清单文件的URL，与繁重的字节传输完全解耦。

边缘缓存（CDN／Open Connect）：承担绝大部分字节的传输；会在需求出现之前，按地区预先放置热门内容。
源站存储：支撑缓存未命中情况的对象存储。
控制平面API：目录、播放授权、收藏——负载体积小，水平扩展，并配有前置缓存。

5. 自适应码率流媒体

在网络条件变化下实现流畅播放，靠的是客户端而非服务器。播放器会监测吞吐量和缓冲水位，并借助清单中的清晰度版本列表在片段之间调高或调低画质——在快速连接上使用更高码率，在慢速连接上降低码率以避免卡顿。

6. 需要说出来的权衡取舍

最后点明面试官想听到的那些张力：预先计算所有清晰度版本的存储成本，与实时转码带来的延迟之间的取舍（Netflix选择预先计算——存储比启动延迟更便宜）；把所有内容都缓存，与只在边缘缓存热门内容之间的取舍（长尾目录不可能全部放在每个边缘节点）；以及像「继续观看」这类控制平面数据的强一致性与最终一致性之间的取舍（最终一致性就足够）。明确说出这些权衡，才能让答案显得老练。

借助实时辅助练习Netflix的系统设计

Natively的系统设计面试助手可以在实际面试中帮你保持结构清晰——实时建议接下来该覆盖哪个维度，并呈现权衡取舍，一切都在你自己的设备上完成。