Netflix系统设计详解

Netflix 是一个订阅制的流媒体平台，会员可以在连接互联网的设备上观看电视节目和电影。

1) 用户应该能够在线观看视频。

2) 跟踪连接到同一账户的多个设备。

3) 用户应该能够通过标题和标签搜索他们想要的视频。

4) 用户应该能够对视频进行评论。

5) 根据历史数据推荐相关视频。

1) 高可用性，同时保持最低延迟。

2) 极其可靠。确保视频不会丢失或损坏。

3) 既可扩展又高效。

4) 让用户享受无延迟的实时视频流。

    **假设条件**  
     1) 允许用户创建账户并订阅套餐。  
    2) 允许用户处理多个账户。

（快速估算）

如果需要严格翻译原文，可以使用：

Netflix 将会有一个读密集型系统，用户不能上传任何视频，只能由 Netflix 自己来执行这一操作。所有由 Netflix 上载的视频均经过验证，并且不会违反任何版权法。

总用户量为 10 亿，日活跃用户（DAU）为 2 亿。每个用户平均每天观看 2 小时的流媒体内容，无论是实时流媒体还是静态内容。

每天观看的总视频小时数为 4 亿小时。每秒请求数为每天 10 亿次请求，相当于每秒 12000 次请求。存储需求如下：

假设 Netflix 有 10000 部电影和剧集等，每部视频大小为 100MB，持续时间为 2 小时。

平均比特率：3 Mbps
每部作品的时长：2 小时

每部作品的存储需求：
3 Mbps × 2 小时 × 3600 秒/小时 = 21600 兆比特 = 2.7 GB

总计存储需求：10000 部视频 × 2.7 GB/部 = 27 TB
冗余副本数：假设为 3 个副本
总存储需求（含冗余）：27 TB × 3 = 81 TB

除了视频存储外，Netflix 还需要为所有订阅者的资料以及每部视频的元数据信息预留单独的存储空间。如果每部视频的最小大小为 100MB，那么存储 10000 部视频需要 1TB 的存储空间。

但由于其内容遍布 100 多个国家，Netflix 作为全球性公司，拥有超过 10000 部内容，几乎涵盖了 Netflix 的所有本地化作品，需要大约 1EB（1,000,000TB）的存储空间。

此外，Netflix 还广泛使用内容分发网络（CDN）进行本地化交付和性能优化。同时，它还使用多层缓存来存储订阅者信息和内容元数据等。

边缘缓存：OCAs 作为边缘服务器，存储经常访问的内容以实现本地化存储。

Open Connect Appliances (OCAs) 部署在全球各 ISP 的数据中心，以缓存流行内容并将其更接近用户。Netflix 大约有 10,000 台 OCA，每台平均容量为 100TB。我们估计全球通过其 Open Connect Appliances 的缓存总量约为 1EB（1,000,000TB）。

**网络带宽**

系统每天需要处理 5PB 的数据流入，相当于需要 58GB/s 的带宽。
最小带宽需求 = 5PB / 24 * 3600 = 58GB/s

**计算资源**

主要用途包括：
-- 流媒体和内容交付
-- 数据分析与处理
-- 推荐系统
-- 开发和测试
-- 通用 IT 基础设施

Netflix 使用 AWS EC2 实例来处理这些任务，
总 EC2 实例数：大约 50000 台
总 vCPU 数：大约 236000 个 vCPU

账单和用户信息采用了MySQL数据库。使用MySQL数据库的原因是为了确保数据的安全和完整性。它支持同步复制，主-主架构，写入操作被视为成功，当数据同时成功写入本地和远程节点。本地和跨区域均设有读取副本。它不仅满足了高可用性需求，还有助于提高可扩展性。

卡萨莎用于媒体内容和观看历史。部分数据未被压缩，其余被压缩存储。

    **# 视频相关API  
     getAllVideo: 获取目录元数据**  
    接口: GET /catalog/titles  
    描述: 获取目录中所有标题的元数据。  
    参数:  
    region (字符串): 需要检索目录的地区。  
    language (字符串): 以何种语言检索元数据。  

    **getVideo: 获取视频详情**  
     接口: GET /catalog/titles/{titleId}  
    描述: 获取特定标题的详细信息。  
    参数:  
    titleId (字符串): 标题的唯一ID。  

    **searchVideo** : 根据标题或标签搜索视频内容 (query, nextpage)。   
    接口: GET /catalog/titles/{tag}  
    参数: 无  
    返回: 视频数据流。  

    **流媒体视频** - GET 请求参数：视频ID, 编解码器, 分辨率, 偏移量。   
    返回: 视频流 (字节流)。  

    **# Netflix用户API**  
     用于管理用户账户和偏好设置。  

    **getuser: 获取用户资料**  
     接口: GET /users/{userId}/profile  
    描述: 获取用户的资料信息。  
    参数:  
    userId (字符串): 用户的唯一ID。  

    **setUserPref: 更新用户偏好**  
     接口: PUT /users/{userId}/preferences  
    描述: 更新用户的偏好设置。  
    参数:  
    userId (字符串): 用户的唯一ID。  
    preferences (JSON): 需要更新的偏好。  

    **getRecommendation: 获取推荐视频**  
     接口: GET /users/{userId}/recommendations  
    描述: 获取用户的推荐视频。  
    参数:  
    userId (字符串): 用户的唯一ID。  
    limit (整数): 要检索的推荐数量。  

    **playback: 开始播放**  
     路径: /playback/start  
    描述: 开始播放特定视频。  
    方法: POST  
    参数:  
    titleId (字符串): 视频的唯一ID。  
    userId (字符串): 用户的唯一ID。

Netflix采用了微服务架构，每个服务的性能都会被追踪。一旦发现问题，会迅速定位并与其他服务隔离。

Netflix 高级架构中的有些主要的组成部分（主要包括 AWS 服务）。

1. ELB：弹性负载均衡器（负载均衡器）有两个层级的负载均衡方案。第一层级是基于DNS的基础轮询负载均衡。首先是跨区负载均衡，然后是实例之间的负载均衡。第二层级的ELB服务是一组负载均衡器实例，这些实例在相同区域内对它们后面的实例进行轮询负载均衡。
2. ZUUL（API网关）处理网络协议、Web服务器、连接管理和代理工作。它有三个独立的过滤器，如入站过滤器用于认证、路由或装饰请求。端点过滤器用于后端服务的请求。出站过滤器用于度量或添加/删除自定义头。其主要用途是将流量分配到不同的集群。
3. Openconnect（CDN）是自定义的全球内容分发网络，用于存储和向全球用户传输电影和电视节目。它们在全球部署了超过1000个位置的Openconnect设备（OCAs）。OCAs可以进行故障转移，流量可以从Netflix用户切换到AWS S3或其他OCAs位置。它使用自适应码率流媒体协议，如HTTP实时流（HLS），旨在提高可靠性，并能够根据网络条件优化播放速度或网络带宽。它还使用视图表中的偏移属性，在特定时间戳处检索场景片段并为用户恢复播放。
4. Hystrix是一个断路器，可以防止级联故障，实时监控配置更改，并具有并发感知的请求缓存和通过请求折叠实现自动批处理。如果微服务无法返回默认响应，则等待其恢复。
5. EVcache用于分布式缓存。当节点失效时，缓存也会丢失，性能会受到打击，直到所有数据重新缓存。但Netflix使用EVcache在多个分片节点上保存多个缓存副本。缓存从最近的缓存或节点读取。如果节点不可用，则从其他可用节点获取数据。使用SSD进行缓存。
6. Kafka用于将不同生产者收集的数据传递给各种消费者。Kafka从前置Kafka向各种接收端传递数据，如S3、Elasticsearch和二级Kafka。
7. Apache Chukwa构建在Hadoop分布式文件系统数据存储之上。Chukwa收集事件并将其写入S3中的Hadoop序列文件格式。大数据平台团队进一步处理这些S3文件，并将它们写入Parquet格式的Hive。但随着最新架构升级，Keystone数据管道用于在云端以大规模收集、聚合、处理和移动数据。它可以处理高达每秒800万事件和每秒24GB的数据，在高峰期。这些事件可以是视频观看活动、UI活动、错误日志、性能事件或故障排查和诊断事件。
8. Elasticsearch（搜索引擎）可以根据标题或相关标签搜索电影或系列。它还用于在出现故障时追踪用户的事件。

Netflix已经定义了处理流媒体视频的服务，比如视频流处理、发布新内容、管理网络流量和在全球服务器间分配资源。

奈飞使用了一个高度复杂的微服务架构，其中包括数百个微服务。架构设计为异步。每个微服务都定义了线程池，例如请求处理线程池和客户端线程池。为了扩展任何操作，将操作拆分成可以并行执行并重新组合的独立进程。异步架构包括用于处理请求响应和客户端交互的事件循环和工作线程。奈飞定义的最常见服务有：

用户服务。

2) 流媒体,

3 搜索服务功能。

4) 媒体服务这一项

5) 数据分析的服务。

6) 在Netflix上的视频处理。

7) 认证服务，比如登录验证。

8) 订阅的服务。

9) 全球搜索功能。

Netflix和YouTube在视频处理方面几乎是一样的。在这里可以参考YouTube的系统架构设计链接。在Netflix中，服务大致可以分为两类。

重要服务 : 需要用户频繁互动。若发生故障转移，用户可以继续使用其他基本服务。

无状态服务：这样的服务响应客户端的API请求。即使某个服务器失败，它们也能继续使用其他可用的服务器，确保高可用性。

为了管理存储并提供高速文件上传和下载，Netflix 设计了一个 文件分块器，将文件分成更小的块。它消除存储中重复数据的副本，并通过仅传输更新的块来减少网络传输的数据量。通常，片段是根据时间戳创建的，因此它们的大小基本相等。但 Netflix 是基于场景来划分这些块的，以便完整地恢复某个场景。

内容审核检查视频是否符合Netflix的内容政策，通常会审核版权、盗版和不合适的内容。

转码工具 可以做比特率调整、图像降采样或重新编码这些工作。

质量转换器将经过转码的媒体转换为不同的分辨率，并将视频上传为所需的分辨率到分布式文件存储，如HDFS、GlusterFS或Amazon S3对象存储等。

一个推荐引擎，使用一种机器学习模型，利用用户的观看历史来预测用户接下来想看的。它采用协同过滤。它还会跟踪多个数据点，例如：

用户资料信息，如年龄、性别和所在位置。

用户的浏览记录和滚动行为。

用户观看预告片的时间和所观看的数据。

搜索次数及搜索的内容是什么。

用于观看流媒体视频的设备。

它还记录分析数据和指标，以捕获来自不同服务的所有数据，并使用 Apache Spark 对数据进行分析。它将关键元数据存储在视图表中，以增加我们数据的丰富度。Spark 还用于内容个性化。大多数成员个性化相关的机器学习管道都在大型托管的 Spark 集群上运行。这些模型是标题的相关性排名、行的选择、排序操作和艺术品的个性化等的基础。

如何识别热门内容？热门内容是基于所有用户的搜索记录。我们可以缓存最近“N”秒内用户最常搜索的查询，并通过每“m”秒执行一次批处理任务来更新这些缓存。

协同过滤（CF算法）的基本思路是，如果两个客户过去对某些事物的评分相似，未来他们的行为也会相似。基于内容的过滤（CB）会推荐给用户更多与他们之前喜欢的电影相似的新电影或项目。混合过滤则是将CB和CF两种方法结合在一起。

Netflix 拥有一个 标题索引模块，该模块会为视频的标题生成索引并将索引更新到 Elasticsearch，以便用户更快地发现内容。

CDN健康检查工具 收集CDN的健康状态指标，并将这些指标存储到数据存储中。

GRPC 作为不同微服务间通信的框架，它轻量且高效，特别适合服务发现。它利用服务网格来管理和观察服务间的通信，并提供双向流传输，操作耦合度最小。

回放流程:

1) 当客户请求播放视频时，该请求会被发送到播放服务。

2) 播放服务调用调度服务来选择可以从其中提供播放的CDN URL。

3) CDN URL返回给客户端。

4) 客户端从CDN下载内容。

5) 客户端将事件发布给播放服务。

6) 播放服务通过调用播放体验服务跟踪事件，以衡量播放体验。

7) 当你流媒体播放视频时，你可以将最近10分钟的视频缓存到本地服务器，而不是每次都从远程获取。

内容搜索流程

1) 用户搜索视频的标题。

2) 内容发现服务（CDS）查询数据库中是否已有该标题。

3) 若在 Elasticsearch 中查找到了该视频标题，CDS 从数据存储中获取详情。

4) CDS 将视频详情返回给用户。

5) CDS 查询内容相似性服务（CSS），CSS 返回相似视频标题列表给 CDS。

6) CDS 从数据存储中获取这些相似视频的详情。

7) CDS 将相似视频的详情返回给用户。

对于像 Netflix 这样的订阅流媒体服务来说，其主要收入来源就是会员费。因此，Netflix 需要管理全球 2.38 亿会员账户。

Netflix的会员系统在管理用户订阅的整个过程起着重要作用

• 注册账号
• 更改计划
• 续订
• 支付相关问题
• 会员暂停或取消服务

架构图的关键点如下：

• 会员平台在全球范围内管理会员计划和定价目录，不同地区有所差异。定价目录服务根据具体地区的提供物来管理规则。
• 使用两个CockroachDB数据库来存储计划定价和代码兑换信息。会员定价服务支持会员操作，例如更改计划或增加额外会员。
• 有一个专用的微服务来处理合作伙伴互动，包括捆绑激活、注册以及与苹果应用商店等平台的集成。
• 会员数据存储在Cassandra数据库中，用于支持订阅服务和历史跟踪服务。
• 平台不仅服务于2.38亿活跃会员，还关注前会员及重新加入的体验。
• 平台生成的数据被发送给下游消费者，以获得关于注册和收入预测的洞察。

在 Netflix 的会员平台初期阶段，会员历史和数据是通过应用程序级别的事件进行跟踪的。为了更细致且持久地跟踪数据，Netflix 开发了一个基于 变更数据捕获（CDC）模式 的更细致的数据跟踪系统。

作为参考，CDC是一种设计模式，它直接捕捉数据库中的更改，并将这些更改传送到下游系统以便进一步处理或分析。

采用类似CDC的方法可以确保所有对成员数据源所做的增量变更都被记录在一个只追加的日志系统里，该系统由一个Cassandra数据库驱动。

1. Netflix 进行的一项重要优化措施是优先级减载。优先级减载是在 Zuul API 网关层 实现的。该系统有效管理各种网络流量，确保关键播放请求优先于不太重要的遥测流量。

PlayAPI 是视频流控平面中的一个关键后端服务，负责处理设备发起的播放列表和许可证请求，以开始播放。PlayAPI 根据请求的紧急程度对其进行分类：

1. 用户主动请求（关键）： 当用户点击播放时发起的请求，这些请求直接影响用户开始观看节目或电影的能力。
2. 预取请求（非关键）： 当用户浏览内容而未点击播放时，系统会提前发起这些请求，以减少用户决定观看某个节目时的等待时间。

它在 PlayAPI 中实现了一个并发限制器，优先处理用户发起的请求，而将预取请求置于次要位置，并且没有通过物理手段将这两种请求处理器分离。当服务器达到并发限制，需要拒绝请求时，优先处理机制才会开始运作。

2. 增量处理，即在工作流中仅对新添加或更新的数据进行处理。这种方法的主要优点是，它只对数据集中的新增或更新的数据进行增量处理，而不需要重新处理整个数据集。这样可以大幅减少计算资源的使用并显著减少执行时间。为了实现增量处理，必须捕捉数据的增量变化并跟踪其状态。能够识别并捕获变化，并从源表捕获这些变化，然后持续跟踪这些变化。

捕获的变更信息必须包括所有相关数据，包括源表中未变更的行。一旦捕获了变更信息（数据或范围），工作流必须以稍微复杂的方式来写入目标表。Netflix 使用仅追加写入（例如 INSERT INTO）来追加新数据到现有数据集。处理完成后，追加的数据会被提交到表里。

我们应该在调用其他服务时处理备用措施、重试和超时，以使服务对各种故障具有弹性。

3. 我们使用RTMP协议来与数据库通信。实时消息传输协议（RTMP） 是由Macromedia（现为Adobe所有）开发的一种用于通过互联网流传输音频、视频以及数据的协议。由于其低延迟的实时特性，RTMP在直播中被广泛使用。RTMP通过将数据拆分成更小的块并通过一个持久的连接进行传输，确保了平稳且不间断的传输。

4. Netflix 非常重视可观测性和监控方面，以确保其会员平台的平稳运行：

• 详尽的日志记录、仪表板和分布式跟踪机制能够实现快速错误检测和解决。在复杂的 Netflix 微服务架构中，这些工具对于识别和解决这些问题的识别和解决是必不可少的。
• 生产报警被设置以跟踪运营指标的跟踪并确保最佳的服务水平。
• 运营数据被用来驱动机器学习模型，从而提高异常检测能力并实现自动化的故障解决过程。这一切都是为了尽量保证用户可以享受不间断的流媒体体验。
• Netflix 使用如 Kibana 和 Elasticsearch 这样的工具来创建仪表板并分析日志数据。当错误率激增时，这些仪表板可以让团队迅速找到引发问题的具体端点并采取纠正措施。

参考链接：
https://medium.com/netflix-techblog/incremental-processing-using-netflix-maestro-and-apache-iceberg-b8ba072ddeeb (Netflix Maestro平台和Apache Iceberg（一个开源的数据存储格式）用于增量处理的相关文章)

https://medium.com/netflix-techblog/enhancing-netflix-reliability-with-service-level-prioritized-load-shedding-e735e6ce8f7d - 提升 Netflix 可靠性：基于服务等级的负载削减策略