NETFLIX系统设计电视电影小迷妹 TVco.cn

如果您不想阅读整篇文章，我有一个关于相同主题的视频

在解释系统设计之前，我将引导您完成Netflix的高级数据流/系统工作。这有助于更好地了解系统组件

Netflix如何在电影/视频上播放：

在向用户提供该电影之前，Netflix必须将视频转换为最适合您的设备的格式。此过程称为代码转换或编码。

转码是将视频文件从一种格式转换为另一种格式，以使视频可以在不同平台和设备上观看的过程。

为什么我们需要这样做？为什么我们不能只播放源视频？

原始的电影/视频采用高清格式，大小为TB级。此外，Netflix支持2200种不同的设备。每个设备都具有在该特定设备上看起来最佳的视频格式。如果您正在iPhone上观看Netflix，则会看到一个视频，该视频可为您提供最佳的iPhone观看体验。

Netflix还创建针对不同网络速度优化的文件。如果您在快速网络上观看，则观看的视频质量会比在慢速网络上观看时的观看质量更高。而且还取决于您的Netflix计划。那说Netflix确实为每部电影创建了大约1200个文件!!!!

要做转码的文件和处理很多，现在我们有了流传输所需的所有文件。 OC Open连接进入图片，OC是Netflix自己的CDN，没有第三方CDN

OC的优势

更便宜
更好的质量
更可扩展

因此，一旦对视频进行了转码，这些文件便被推送到所有OC服务器。

现在第二种情况：

当用户加载Netflix App时，所有请求均由服务器在AWS Eg中处理：登录，建议，主页，用户历史记录，账单，客户支持等。现在，您想在单击视频的播放按钮时观看视频。您的应用会自动为您找出最佳的OC服务器，最佳的格式和最佳的比特率，然后从Open Connect CDN中的附近的Open Connect设备（OCA）传输视频。

Netflix应用程序是如此智能，以至于它们不断为您检查最佳的流媒体服务器和比特率，并在格式和服务器之间进行切换，从而为您提供最佳的观看体验。

现在Netflix所做的就是与您在使用Hadoop的AWS上进行的所有搜索，查看，位置，设备，评论和喜欢数据有关。机器学习模型可以推荐您可能喜欢的新电影…

这个循环不断

Netflix支持2200种不同的设备，包括智能电视，Adroid，IOS，游戏机，网络应用等

所有这些应用程序都是使用特定于平台的代码编写的。

Netflix喜欢React JS：

React受许多因素影响，最值得注意的是：1）启动速度，2）运行时性能和3）模块化

ELB：

Netflix使用Amazon的Elastic Load Balancer（ELB）服务将流量路由到我们的前端服务。设置ELB，以便首先在区域之间均衡负载，然后在实例之间均衡负载。这是因为ELB是两层负载平衡方案。

第一层包括基于基本DNS的循环负载平衡。这样会将客户端带到云中的ELB端点，该端点位于您的ELB配置为使用的区域之一中。
ELB服务的第二层是负载均衡器实例的数组（由AWS直接提供），该负载均衡器对同一区域中它背后的我们自己的实例进行循环负载均衡。

ZUUL：

过滤器前面和后面的Netty处理程序主要负责处理网络协议，Web服务器，连接管理和代理工作。随着内部工作的抽象化，过滤器完成了所有繁重的工作。

入站筛选器在代理请求之前运行，可用于身份验证，路由或修饰请求。

端点过滤器可以用于返回静态响应，也可以将请求代理到后端服务（或我们称为源的代理）。

出站筛选器将在返回响应后运行，并且可以用于gzipping，指标或添加/删除自定义标头之类的事情。

特征：

支持http2
相互TLS
自适应重试
源的并发保护

它有助于基于查询参数，URL，路径的轻松路由。主要用例是将流量路由到特定的测试或暂存群集。

优点：？？

需要分流流量的服务会创建路由规则，将某些路径或前缀映射到单独的来源
开发人员通过创建将新主机名映射到其新来源的路由来使用新服务
开发人员通过将一部分现有流量路由到小型集群并确保应用程序在负载下正常降级来运行负载测试
重构应用程序的团队通过创建逐渐映射流量的规则（一次一条路径），将应用程序缓慢迁移到新的来源
团队通过将少量流量发送到运行新版本的检测群集来测试更改（canary测试）
如果团队需要在新版本上测试需要多个连续请求的更改，则可以运行粘性金丝雀测试，将相同的用户在短时间内路由到新版本
安全团队根据所有Zuul群集中的路径或标头规则创建拒绝“不良”请求的规则

Hystrix：

Hystrix是一个延迟和容错库，旨在隔离对远程系统，服务和第三方库的访问点。这有助于

停止级联故障
实时监视配置更改
并发请求缓存
通过请求折叠自动进行批处理

IE浏览器如果微服务失败，则返回默认响应并等待其恢复。

微服务：

APIS如何获得响应？

Netflix使用MicroServices架构来支持应用程序和Web应用程序所需的所有API。每个API调用其他微服务以获取所需数据，然后以完整响应进行响应

此设置有效，但是可靠吗？

我们可以使用我已经解释过的Hysterix
我们将关键服务分开

关键微服务：

Netflix所做的是，他们将很少的服务确定为关键服务（以便在级联服务失败的情况下，最终用户可以看到推荐的即插即用功能），并且这些微服务可以在不依赖其他服务的情况下正常工作！

无状态服务：

Netflix体系结构的主要设计目标之一是无状态服务。

这些服务的设计使得任何服务实例都可以及时处理任何请求，因此，如果服务器发生故障，这没什么大不了的。发生故障时，案例请求可以路由到另一个服务实例，我们可以自动启动一个新节点来替换它。

EVCache：

当节点发生故障时，所有缓存都将随之关闭。因此性能会一直下降，直到所有数据都被缓存为止。因此Netflix所做的就是他们提出了EVcache。它是Memcached的包装器，但经过分片，因此缓存的多个副本存储在分片的节点中。因此，每次写入发生时，所有分片也会被更新…

发生高速缓存读取时，请从最近的高速缓存或节点中进行读取，但是当某个节点不可用时，请从其他可用节点中进行读取。它每天可处理3000万个请求，并具有毫秒级延迟的线性可扩展性。

用于缓存的SSD：

将大量数据存储在易失性存储器（RAM）中非常昂贵。基于SSD的现代磁盘技术可提供对数据的快速访问，但与RAM相比，其成本要低得多。因此，我们希望将部分数据移出内存，而不牺牲可用性或性能。在SSD上存储1 TB数据的成本远低于存储相同数量的RAM。

数据库：（EC2部署的MySQL）

最终，EC2 MySQL是计费/用户信息用例的选择，Netflix使用InnoDB引擎大型ec2实例构建了MySQL。他们甚至使用“同步复制协议”进行安装，从而使主节点上的写操作被视为已完成。仅在确认本地和远程写入之后。

结果，保证了单个节点的丢失没有数据丢失。这将影响写入延迟，但这完全在SLA中。

在本地以及跨区域设置的只读副本不仅满足高可用性要求，而且有助于扩展性。

来自ETL作业的读取流量已转移到只读副本，从而使主数据库免于繁重的ETL批处理。如果主MySQL数据库发生故障，则会执行故障转移到以同步模式复制的辅助节点。一旦辅助节点接管主要角色，数据库主机的route53 DNS条目将更改为指向新的主要节点。

Cassandra：-> 500个节点50个群集

Cassandra是一个免费的开放源代码的分布式宽列存储NoSQL数据库，旨在处理许多商用服务器上的大量数据，提供高可用性而没有单点故障

在Netflix，随着用户群的增加，观看历史数据的数量也大大增加。

最初的日子还不错，但时间不长

因此，Netflix重新设计了数据存储架构，并牢记了两个主要目标：

较小的存储空间。
随着每个成员查看次数的增加，一致的读/写性能。

所以解决方案：压缩旧行！数据分为两种类型

实时观看历史记录（LiveVH）：少量的近期观看记录，且频繁更新。数据以未压缩的形式存储，如上面详述的简单设计一样。

压缩的观看历史记录（CompressedVH） ：大量较旧的观看记录，很少进行更新。数据经过压缩以减少存储空间。压缩的查看历史记录存储在每行键的单个列中。

Kafka到chukwa进行分布式系统监视

将所有netflix事件推送到处理管道

每天约有5000亿个事件和约1.3 PB

高峰时段约有800万个事件和每秒约24 GB

什么样的事件？

视频观看活动
UI活动
错误日志
演出活动
故障排除和诊断事件

Apache Chukwa是一个用于监视大型分布式系统的开源数据收集系统。 Apache Chukwa建立在Hadoop分布式文件系统（HDFS）和Map / Reduce框架之上，并继承了Hadoop的可扩展性和健壮性。

Apache Chukwa还包括一个灵活且功能强大的工具包，用于显示，监视和分析结果，以充分利用收集到的数据。

kafka路由服务负责将数据从前端的Kafka移动到各种接收器：S3，Elasticsearch和辅助Kafka。

路由是使用apache Samza完成的

当Chukwa将流量发送到Kafka时，它可以传递完整或已过滤的流。有时，我们需要对Chukwa编写的Kafka流进行进一步过滤。这就是为什么我们要让路由器从一个Kafka主题消费并生成另一个Kafka主题。

弹性搜寻：

过去两年来，我们发现Netflix在Elastic搜索中的采用呈爆炸式增长。有约150个群集，总计约3500个实例，承载着约1.3 PB的数据。绝大多数数据是通过我们的数据管道注入的。

Netflix如何使用它

假设某个客户尝试播放视频而他却无法播放视频，他现在就致电客户服务中心，客户服务人员如何调试发生的情况？因此，回放小组使用弹性搜索来深入研究问题，并了解问题的广泛程度。

查看注册或登录问题
跟踪资源使用情况

AWS应用程序自动扩展功能— TITUS

Titus是一个容器管理平台，可提供可扩展且可靠的容器执行以及与Amazon AWS的云原生集成。

Titus是在Netflix内部建立的，并在生产中用于驱动Netflix流，推荐和内容系统。

它还具有对服务应用程序的调度支持。主要用于扩展docker映像，它使用AWS API网关与AWS自动扩展服务进行通信，以在AWS上扩展docker。

AWS自动扩展可以扩展实例，Titus将根据流量条件扩展实例以及泊坞窗。由于Netflix在docker上有许多微服务。

例如，当美国东海岸的人们下班回家并开启Netflix时，服务会自动扩展以满足这种需求。根据需求动态缩放而不是静态调整有助于确保服务可以自动满足各种流量模式，而服务所有者无需调整大小和规划所需容量。此外，动态扩展使不需要用于其他目的（例如编码新内容）的云资源成为可能。

此设计围绕AWS Auto Scaling引擎进行，该引擎能够计算Titus服务所需的容量，将该容量信息中继给Titus，并让Titus通过启动新容器或终止现有容器来调整容量。这种方法有几个优点。首先，Titus能够利用为AWS提供支持的经验证的自动缩放引擎，而不必构建自己的引擎。其次，Titus用户将使用与EC2熟悉的相同的目标跟踪和逐步扩展策略。第三，通过将应用程序发布到CloudWatch以及它们特定于AWS的指标（例如SQS队列深度），应用程序将能够根据自己的指标（例如每秒请求或容器CPU利用率）进行扩展。第四，Titus用户将从AWS引入的新的自动扩展功能和改进中受益。

关键的挑战是使AWS Auto Scaling引擎能够调用在Netflix的AWS账户中运行的Titus控制平面。为了解决这个问题，我们利用了AWS API Gateway，该服务提供了AWS可以调用的可访问API“前门”以及可以调用Titus的后端。 API Gateway为AWS公开了一个通用API，可用于调整资源容量并获取容量状态，同时允许正在扩展的资源的可插入后端实现，例如Titus上的服务。在Titus服务上配置自动扩展策略后，Titus会使用AWS Auto Scaling引擎创建新的可扩展目标。

入职时及以后的媒体处理

验证视频：Netflix要做的第一件事是花费大量时间来验证视频。它查找可能由先前的代码转换尝试或数据传输问题引起的数字伪像，颜色变化或丢失的帧。

如果发现任何问题，视频将被拒绝。

验证视频后，将其输入到Netflix所谓的媒体管道中。

流水线只是一系列步骤，数据经过处理才能准备就绪，就像工厂的流水线一样。 70多种不同的软件可帮助您制作每个视频。

处理单个多TB大小的文件是不切实际的，因此，管道的第一步是将视频分成许多较小的块。

然后将视频块放入管道中，以便可以并行编码它们。并行仅表示块在同一时间处理

射手：

Archer是易于使用的MapReduce样式平台，用于使用容器的媒体处理，因此用户可以带来其操作系统级别的依赖关系。平台会处理常见的媒体处理步骤，例如安装视频帧。开发人员编写三个函数：拆分，映射和收集；他们可以使用任何编程语言。 Archer专门为大规模的简单媒体处理而构建，这意味着该平台了解媒体格式，并为流行的媒体格式提供了白手套处理。

例如，PRORES视频帧是Archer中的头等对象，并且开箱即用地将视频源拆分为基于镜头的块[1]（镜头是摄像机不移动的视频片段）。

检测数码相机故障造成的坏点
机器学习（ML）标记音频
字幕质量控制

SPARK影片推荐的用法

Spark用于内容推荐和个性化。大多数用于成员个性化的机器学习管道都在大型托管Spark集群上运行。这些模型构成了推荐系统的基础，该系统支持您在Netflix应用上看到的各种个性化画布，包括标题相关性排名，行选择和排序以及图稿个性化等。

Netflix为您量身定制艺术品

这是Netflix如何利用其数据分析功能吸引您观看更多视频的一个很好的例子。

在四处寻找在Netflix上观看的内容时，您是否注意到每个视频始终显示一个图像？这就是标题图片。

标题图片旨在吸引您，吸引您选择视频。这个想法是标题图像越引人注目，您观看视频的可能性就越大。而且，您观看的视频越多，您退订Netflix的可能性就越小。

这是陌生人事物的不同标题图像的示例：

了解为每个视频专门选择的显示图像，您可能会感到惊讶。并非所有人都看到相同的图像。

每个人都曾经看到相同的标题图像。这是它的工作方式。随机显示一组选项中的成员一张图片，如上面的“陌生人事物”拼贴中的图片。 Netflix会在每次观看视频时进行计数，记录选择视频时显示的图片。

对于我们的“陌生事物”示例，假设显示了中央的集体照时，“陌生事物”被观看了1,000次。对于其他所有图片，每张只观看一次。

由于集体照是吸引成员观看的最佳方式，因此Netflix会使其永远成为Stranger Things的标题图像。

这称为数据驱动。 Netflix以数据驱动公司而闻名。在这种情况下，将收集数据（在这种情况下为与每个图片关联的视图数），并用于做出最佳决策，从而选择哪个标题图像。

聪明，但是你能想象做得更好吗？是的，通过使用更多数据。这就是未来的主题-通过学习数据来解决问题。

你和我可能是截然不同的人。您是否认为我们受到相同类型的标题图片的激励？可能不会。我们有不同的口味。我们有不同的偏好。

Netflix也知道这一点。因此，Netflix现在可以个性化显示给您的所有图像。 Netflix会尝试选择与您的视频最相关的艺术品。他们是如何做到的？

请记住，Netflix记录并统计您在其网站上所做的一切。他们知道您最喜欢哪种电影，最喜欢哪些演员等等。

Netflix的推荐系统如何运作

https://beta.vu.nl/nl/Images/wer…

每当您访问Netflix服务时，我们的推荐系统都将尽力帮助您轻松找到想要欣赏的节目或电影。我们根据多种因素估算您观看我们目录中某个特定标题的可能性，其中包括：

•您与我们的服务的互动（例如，您的观看历史记录以及您如何评价其他标题），

•其他对我们的服务有喜好和喜好的会员（此处有更多信息），以及

•有关标题的信息，例如其类型，类别，演员，发行年份等。

除了了解您在Netflix上观看过的节目之外，为了使建议更加个性化，我们还着眼于以下方面：

•您一天中的观看时间，

•您正在观看Netflix的设备，以及

•您观看多长时间。

协作过滤协作过滤（CF）算法基于这样的思想，即如果两个客户具有相似的评级历史记录，那么他们将来的行为就会类似（Breese，Heckerman和Kadie，1998年）。例如，如果有两个非常可能的用户，并且其中一个观看了电影并以良好的评分对其进行了评分，则可以很好地表明第二个用户的模式相似

基于内容的筛选基于内容的筛选（CB）旨在推荐与用户之前喜欢的电影相似的项目或电影。这种方法与CF的主要区别在于，CB不仅根据评分的相似性提供推荐，而且更多地涉及产品信息（Aggarwal，2016年），例如电影名称，年份，演员，流派。为了实施该方法，必须拥有描述每个项目的信息，并且还需要某种描述用户喜欢的用户简档。任务是学习用户首选项，然后找到或推荐与用户首选项“相似”的项目

混合过滤混合方法的特征在于结合了CF和CB技术