设计类 YouTube 应用：深入了解视频流架构

YouTube 已成为视频共享和流媒体的代名词。无论你是想掌握食谱、学习编码，还是观看苹果公司发布最新的技术创新，YouTube 都能满足你的需求。很难想象没有这个平台的日子，它已经发展成为全球最大的视频共享服务之一。

但在这个看似简单的界面背后，却隐藏着一个极其复杂的系统。建立一个平台，满足数十亿用户的需求，每天处理数 PB 的数据，并在全球范围内提供流畅的体验，这绝非易事。设计 YouTube 或任何如此规模的系统都需要工程智慧和谨慎的优先排序。

在本文中将分析创建 YouTube 这样的视频流媒体平台所面临的设计挑战和解决方案。虽然该平台已发展到包括无数功能（如直播、社区帖子和个性化推荐），但我们将重点关注其基础元素。了解其核心要素将有助于我们深入了解是什么让这样一个系统能够大规模运行。

功能要求

让我们从最基本的开始。YouTube 刚推出时需要做什么？该平台的核心功能要求如下：

1. 跨设备流式传输视频：YouTube 的支柱是视频播放。用户需要毫不费力地播放视频，无论他们是在通勤途中使用手机、在工作中使用台式机，还是在家中使用智能电视。无论设备类型或屏幕分辨率如何，体验都应该是无缝的。

2. 视频上传和共享：没有用户生成的内容，YouTube 就不是 YouTube。该平台需要为用户提供上传视频的直接方式。视频上传后，必须能够通过链接、嵌入或其他社交渠道轻松分享，使创作者能够接触到更多受众。

3. 互动功能：点赞、评论和订阅等功能可以增强用户体验，但对于平台的核心功能而言，这些功能只是次要的。这些功能对用户参与很重要，但并不能从根本上定义视频流媒体服务，因为它们在许多其他平台上都很常见。

4. 通过字幕实现无障碍：字幕改变了可访问性。它能消除语言障碍，使听力受损的用户也能使用内容。虽然这对包容性至关重要，但在最初设计时可将其作为次要功能。

非功能性要求

仅有功能是不够的，系统的性能也同样重要。以下是关键的非功能性要求，它们为 YouTube 这样的高质量平台设定了标准：

1. 低延迟播放：没有什么比点击播放然后等待视频加载更让人沮丧的了。YouTube 需要尽快开始视频流。虽然在极端情况下，轻微的延迟是可以忍受的，但最大限度地减少延迟对用户满意度至关重要。

2. 适用于所有速度的自适应流媒体：并非每个人都能使用极速网络。即使连接速度较慢，系统也需要提供流畅的播放体验。自适应比特率流（ABR）可确保根据用户的带宽动态调整视频质量，使缓冲现象很少发生。

3. 高可用性：对于 YouTube 这样的平台来说，宕机是不允许的。无论是凌晨 3 点播放视频的人，还是上传最新杰作的内容创作者，平台都需要可靠。不过，我们可以优先考虑可用性而不是一致性–如果新上传的视频需要一点时间才能出现，或者订阅同步稍有延迟，这都是可以接受的。完全中断或无法串流视频则是不可接受的。

关键组件和初始 API

在设计 YouTube 时，核心重点必须放在视频上，因为视频是全场的主角。为了建立视频共享平台的基础，我们从两个基本的 API 开始：

1. 视频上传：

1 POST /upload

该 API 可让用户上传视频。这不仅仅是存储文件那么简单。系统必须处理不同格式的视频，生成元数据（如分辨率、长度和缩略图），并为自适应流媒体做好准备。

2. 视频播放：

 GET /videos

视频上传后，用户需要一种访问视频的方式。该应用程序接口根据视频的唯一标识符获取视频，并以符合用户设备和网速的格式提供视频。它是 YouTube 核心功能的入口。

上传 API：为全球受众高效上传视频

上传视频是内容创作者与世界分享作品的入口。像 YouTube 这样的平台每天要处理数百万用户的上传，要为其设计这一功能，效率和可扩展性至关重要。首要的要求是允许用户无缝上传视频，同时尽量减少系统瓶颈和资源使用。为实现这一目标，我们对设计进行了改进，从简单的服务器介导上传流程转变为利用预签名 URL 直接上传至亚马逊 S3 等存储服务的流程。

当用户启动上传流程时，交互始于对 POST /presignedUrl API 的调用。通过 API 网关发送的这一请求只包含视频的元数据，如标题、描述、标签以及与视频相关的任何其他信息。实际的视频文件不会在此阶段上传。API 网关会将此请求路由到媒体服务，媒体服务会执行初步验证，如确保标题长度在可接受范围内，标签符合预期格式。

验证成功后，媒体服务会在视频元数据数据库中创建一个条目。该条目包括以下基本属性：

唯一的视频 ID
标题
描述
标签
S3 中最终存储位置的占位符
其他元数据，如上传者的 ID、上传时间戳和隐私设置，也可以记录在这里。

下一步涉及媒体服务使用 S3 生成预签名 URL。此 URL 为客户端提供临时、安全的访问权限，以便将视频直接上传到 S3，而无需视频数据流经 API 网关或媒体服务。通过将实际上传任务转移给客户端，系统可减少带宽使用量和服务器负载，从而显著提高整个过程的效率。

生成预签名 URL 后，它会返回给客户端。然后，客户端会将视频直接上传到 S3，绕过通过 API 网关或媒体服务的中间跳转。此流程特别有利，因为它将上传机制与应用程序的核心分离，使系统能够独立于上传量进行扩展。

为什么存储 RAW 文件不切实际

一种简单的设计可能会将上传的 RAW 视频文件直接存储在 S3 中，但这种方法忽略了对可扩展性和用户体验的重要考虑。RAW 视频文件较大，且未对播放进行优化。例如，1 分钟的 1080p RAW 视频可能占用多达 1 GB 的存储空间。相比之下，使用 H.264 等高效编解码器编码的压缩版视频可能只需要 10 MB。这意味着可节省 100 多倍的存储空间和带宽，因此在最终存储前对视频进行处理和压缩至关重要。

除了存储效率，设备兼容性也是另一个关键因素。不同的设备支持不同的视频编解码器。例如，智能手机通常支持 H.264 或 H.265 编解码器，而智能电视可能需要 VP9 或 AV1。如果不将 RAW 视频文件转码为多种格式，在不兼容的设备上播放可能会失败。此外，为确保流畅的流媒体体验，视频需要以不同的分辨率和比特率进行编码，以支持自适应比特率流（ABR）。这种技术使平台能够根据观看者的网络速度动态调整视频质量，确保即使在较慢的连接上也能将缓冲降至最低。

数据库和存储设计：一种协作方法

上传流程依赖于视频元数据数据库和S3 存储之间的紧密集成。数据库充当系统的大脑，管理有关视频的所有元数据，例如其标题、描述、标签和存储位置。它不存储视频本身，而是作为促进高效搜索和检索的参考系统。

另一方面，S3 是视频内容的主要存储。最初，RAW 视频文件可能暂时存储在 S3 中以供后期处理。转码后，各种格式和分辨率的处理后的文件将存储在单独的 S3 对象中。此外，S3 还存储在处理阶段生成的缩略图，这些缩略图将作为视频预览显示给用户。

完善上传 API

考虑到这些因素，POST /upload 端点演变为更完善的 POST /presigned_url API。此更新的 API 专注于元数据提交和预签名 URL 生成，将视频上传的繁重工作留给客户端。这种设计不仅提高了系统效率，还为可扩展的视频共享平台奠定了基础。

这种方法可确保上传过程稳健、高效且可扩展，满足全球用户群的需求。接下来，我们将深入了解如何处理视频并将其传送给观看者，以确保全球数十亿用户能够无缝播放。

分割

管理视频上传和回放的良好解决方案包括存储不同的视频格式，以支持各种设备和网络条件。一旦用户上传视频，系统就会接管，利用 S3 的事件通知功能触发视频处理服务。该服务负责将原始视频转换成多种格式和分辨率，确保智能手机、平板电脑、台式机和智能电视等设备的兼容性。然后将每种格式作为单独的文件存储在 S3 中，并更新视频元数据记录以包含这些文件的 URL。

虽然这种方法解决了格式兼容性问题，但却带来了一个关键的低效率问题：视频是作为完整文件存储的。在播放过程中，必须下载或流式传输整个视频文件或其中的大部分，从而导致更高的延迟和带宽消耗，尤其是对于较长的视频。这就需要采用更先进的解决方案：将视频分割成更小、更易于管理的片段。

为什么视频分割更好

与将整个视频存储为单个文件相比，将视频分割为较小的单元（通常为几秒钟长）具有多种优势。每个片段都是一个独立的可播放单元，允许系统只获取播放所需的部分。这种方法与自适应比特率流相结合，即使在网速不稳定的情况下也能实现无缝观看体验。

例如，当用户开始播放视频时，播放器会请求播放前几个片段。随着播放的继续，会动态获取更多片段。如果用户寻找视频中的不同点，系统可以直接检索相应的片段，而不是下载文件中不必要的部分。这就减少了延迟，提高了资源效率。

此外，分段还可将每个片段转码为多种格式。例如，一个 10 秒的片段可能有 240p、360p、720p 和 1080p 四种分辨率，并采用 H.264、VP9 或 AV1 等不同的编解码器进行编码。这样，视频播放器就能实时适应用户的设备和网络条件，根据需要在不同格式和分辨率之间无缝切换。

分段和转码过程

该过程从视频处理服务开始。收到 S3 发送的新视频已上传的通知后，该服务将执行以下步骤：

视频分段：原始视频被分成小块，通常为 2 到 10 秒长。每个片段都是一个完整的可播放单元，具有自己的音频和视频数据。

转码：每个片段都会被编码成多种格式和分辨率。例如，单个片段可能会被转码成：

H.264，360p、720p 和 1080p
VP9 分辨率为 360p、720p 和 1080p
AV1 分辨率为 480p 和 1080p

存储：转码后的片段存储在 S3 中，按视频 ID、分辨率和编解码器进行组织。元数据条目使用每个片段的 URL 进行更新，从而提供给定视频所有可用格式的综合映射。

基于分段的存储如何改善流媒体

通过将视频存储为片段，系统可以有效地实现 HLS 或 DASH。这两种协议都依赖于分段视频文件和随附的清单文件，该文件为播放器提供视频的结构和可用的格式。

例如，清单文件列出：

所有可用的分辨率和编解码器
段 URL 的顺序
每个片段的比特率信息

视频播放器使用此清单动态请求片段。如果用户的网络速度下降，播放器可以无缝切换到较低分辨率的片段，而不会中断播放。相反，当连接改善时，会获取更高分辨率的片段以提高视频质量。

解决细分难题

虽然细分带来了显着的优势，但也带来了复杂性：

同步：音频和视频必须在所有片段中保持完美同步。这需要在分割过程中进行精确的编码和对齐。
存储开销：为每个片段存储多种格式会增加存储需求。有效的压缩和谨慎的格式选择可以缓解这种情况。
清单管理：系统必须确保清单文件始终准确，并在添加新片段或修改格式时进行更新。

尽管存在这些挑战，但分段的优势（增强播放效率、减少延迟以及支持自适应流媒体）使其成为 YouTube 等现代视频平台的最佳方法。

设计流媒体系统

当用户想要观看视频时，体验取决于高效的流媒体、自适应质量以及确保最少的中断。设计如下：

获取元数据和初始设置

流式传输视频的第一步是检索其元数据。元数据包含基本详细信息，包括存储在 S3 中的视频片段的位置和清单文件的 URL。客户端发出请求GET /video，系统使用这些 URL 进行响应。

清单文件在组织视频片段方面起着至关重要的作用。它充当路线图，指导客户端逐步获取片段。通过引用清单，客户端可以避免下载整个视频文件，这会导致严重的效率低下。例如，在 100 Mbps 的连接上下载 10 GB 的视频可能需要 13 分钟以上——这对现代用户来说是不合理的延迟。

客户端无需等待完全下载，而是逐步传输视频。这种方法不仅改善了用户体验，还节省了带宽并降低了中断的可能性。如果由于网络问题导致下载失败，则只需重新获取一小段，从而最大限度地减少浪费的时间和资源。

增量流和自适应比特率

增量流式传输让用户可以几乎立即开始观看视频。其工作原理如下：

客户端获取包含视频片段引用的清单文件。
它根据网络速度、设备功能或用户偏好选择初始视频格式（例如 480p、720p 或 1080p）。
下载并播放第一片段，通常为几秒钟的长度。
随着播放的继续，后续片段将在后台获取，确保无缝流式传输。

然而，网络状况可能会波动。如果客户端开始下载 1080p 片段，但连接变弱，则可能会发生缓冲，从而降低用户体验。为了解决这个问题，系统实施了自适应比特率流 (ABR)。

ABR的工作原理

ABR 可确保即使网络条件发生变化也能流畅播放。客户端会监控连接速度并动态调整分辨率。以下是详细流程：

客户端检索清单文件并根据初始网络条件选择分辨率。
如果网络速度变慢，客户端就会切换到较低分辨率的片段以避免缓冲。
相反，如果条件改善，则获取更高分辨率的片段以获得更好的质量。

这种适应性可以在优化数据使用的同时保持不间断播放。

流媒体视频处理

为了支持自适应流式传输，视频处理管道会准备视频，以便在各种设备和条件下进行传输。管道输出：

片段文件：原始视频被分成几个较小的片段，每个片段都以多种格式和分辨率进行编码。
清单文件：这些文件组织各个片段，其中主清单引用不同分辨率的媒体清单。

该过程包括：

分割：使用诸如之类的工具ffmpeg，将原始视频分成短的、固定持续时间的片段。
转码：每个片段都编码成 H.264 或 H.265 等格式，兼容多种设备。
清单创建：清单文件将片段链接到其各自的分辨率和格式。

处理后，可以根据系统要求存档或删除原始视频，平衡存储成本和检索需求。

可续传上传：为用户提供可靠性

处理不完整的上传对于用户满意度至关重要。系统使用基于块的可恢复上传机制：

客户端将视频分成小块（每块约 5-10 MB），每个小块由唯一的指纹哈希值标识。
VideoMetadata表记录每个块的上传状态（例如，NotUploaded 或 Uploaded）。
当块上传到 S3 时，事件通知会更新数据库。
如果上传中断，客户端将通过获取元数据来识别并重新上传丢失的块，从而恢复上传。

这确保了可靠上传，而不会浪费带宽或用户时间。

了解 YouTube 的后端请求结构

让我们检查一下 YouTube 视频播放 URL，以了解视频流的工作原理，包括其安全措施、会话管理、自适应流和内容传送机制。

以下是供分析的示例 URL：

https://rr3---sn-npoe7ns6.c.youtube.com/videoplayback?expire=1735662527&ei=X8dzZ8WNGOKe4t4P45LauQc&ip=2402%3Ae280%3A2108%3A1ee%3Aadef%3A3256%3A96a0%3Ae5d6&cp=X19SZmV3cGYtNk1ET0pVS0I6OExxby1GR1hPa3NGbkdjSDdLY3h5eTdmNVFSTVZOay1mQUEtWVh4WVFKMw&id=o-AJDE1qKSsMRStRgH5IGrbKLhyoZlGrfiVtMfccCMLFZG&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&sc=yes&pcm2=no&siu=1&spc=x-caUHNGrKU3vEC6KefuJlKfIXkkBA8fvOojcoLqul9Cf4xIOmcwy3pUzDNNKGpz59I04dttxFd2MvA&svpuc=1&ns=2WNYqoS4LLUsADHlIuytzbIQ&sabr=1&rqh=1&keepalive=yes&fexp=51326932%2C51335594%2C51355912&c=WEB&n=IjewtLWCSVCuwg&sparams=expire%2Cei%2Cip%2Ccp%2Cid%2Csource%2Crequiressl%2Cxpc%2Cpcm2%2Csiu%2Cspc%2Csvpuc%2Cns%2Csabr%2Crqh&sig=AJfQdSswRgIhAKYSPhT9klkjnENyP9hCXfygk--cDAubSyYcr5BGT25iAiEAh7sqFXG0ADDVdPA5ldRUpSHTaGEhy_F9OOm94ZBP1nU%3D&cpn=L9wSxTxSDP1A2x_-&cver=2.20241219.01.01&redirect_counter=1&cms_redirect=yes&cmsv=e&met=1735640929,&mh=Oa&mm=34&mn=sn-npoe7ns6&ms=ltu&mt=1735640692&mv=m&mvi=3&pl=48&rms=ltu,su&lsparams=met,mh,mm,mn,ms,mv,mvi,pl,rms,sc&lsig=AGluJ3MwRgIhAPO6UexG1sAyPRK_0tGWG3lXky-NCI3V5gBfWtd80SFwAiEApdQHpb299_3ltm_AvdiAJRjS9sHo_I64oyGmKK_a58Q%3D&rn=119&alr=yes

URL 组件

让我们分解一下此 URL 的关键元素：

https://rr3---sn-npoe7ns6.c.youtube.com/videoplayback

– rr3 — -sn-npoe7ns6.c.youtube.com：此域名指向 YouTube 的视频传输基础设施。rr3 指的是 CDN（内容传输网络）网络中的特定服务器或数据中心位置，可帮助 YouTube 从最近的可用服务器高效地传输视频流。

– videoplayback：指定播放视频的操作。

到期和安全参数：

expire=1735662527：此 URL 的到期时间的 Unix 时间戳，为视频提供有限的访问窗口。
ei=X8dzZ8WNGOKe4t4P45LauQc：请求的唯一标识符，用于会话跟踪和错误处理。
ip=2402%3Ae280%3A2108%3A1ee%3Aadef%3A3256%3A96a0%3Ae5d6：请求视频的用户的编码 IP 地址，允许 YouTube 识别客户端的位置以进行 CDN 路由和访问控制。
cp=X19SZmV3cGYtNk1ET0pVS0I6OExxby1GR1hPa3NGbkdjSDdLY3h5eTdmNVFSTVZOay1mQUEtWVh4WVFKMw：可能是用于内容保护的令牌（例如，DRM 或地理限制信息），以确保只有授权用户才能访问视频。

视频特定参数：

id=o-AJDE1qKSsMRStRgH5IGrbKLhyoZlGrfiVtMfccCMLFZG：所请求特定内容的唯一视频标识符。
source=youtube：表示请求来自YouTube平台。
requiressl=yes：强制使用 SSL（安全套接字层）来确保视频流期间的安全通信。
xpc=EgVo2aDSNQ%3D%3D：可能用于跨页面通信或会话管理的附加令牌。
sc=yes：可能表示是否允许根据某些条件（例如地理位置、订阅）进行视频流传输。
siu=1：可以指示用于管理连接的会话或流 ID。
spc=x-caUHNGrKU3vEC6…：一个唯一的令牌，可能与数字版权管理 (DRM) 或访问控制相关，确保以安全的方式查看内容。

自适应流和缓冲：

svpuc=1：指示自适应视频质量是否启用的标志。
sabr=1：表示已启用自适应比特率流。这允许 YouTube 根据用户的网络状况调整视频质量。
rqh=1：可能表示播放期间某些 QoS（服务质量）措施是否处于活动状态。
keepalive=yes：确保流会话期间连接保持活动状态，防止播放期间超时。

实验和 A/B 测试参数：

fexp=51326932%2C51335594%2C51355912：YouTube 使用这些标记进行实验性功能、A/B 测试或优化策略。这些标记可能因客户端版本和 YouTube 的内部测试而异。
c=WEB：指定通过 Web 客户端（基于浏览器）请求视频。

客户端信息和版本：

n=IjewtLWCSVCuwg：用于跟踪会话信息或视频播放事件的客户端特定标识符。
cver=2.20241219.01.01：正在使用的客户端版本，确保与 YouTube 的后端和功能兼容。
cpn=L9wSxTxSDP1A2x_-：可用于会话管理或用户跟踪的客户端特定令牌。

重定向和 CMS 参数：

redirect_counter=1：URL 经历的重定向次数。如果为了实现最佳交付而将内容在服务器之间移动，则可能会发生这种情况。
cms_redirect=yes：表示由于 YouTube 的内容管理系统而发生了内容重定向。
cmsv=e：代表内容管理版本。

播放和交付优化：

met=1735640929,：与视频请求相关的元数据，可能链接到时间戳或缓存系统。
mh=Oa：代表媒体主机类型，是 YouTube 内部 CDN 基础设施的一部分。
mm=34：指定所请求的媒体类型（可能是视频流）。
mn=sn-npoe7ns6：该参数表示正在使用的服务器节点，将请求引导至YouTube的CDN中的相应服务器。
ms=ltu：可能指定正在使用的服务器类型（例如，低延迟服务器）。
mt=1735640692：指示请求时间的时间戳。
mv=m：这指的是媒体版本（可能是视频流的格式或编码）。
mvi=3：表示请求的视频索引或视频的具体版本。

质量和资源管理：

pl=48：指定特定的播放列表或播放质量级别。
rms=ltu,su：资源管理标志，用于确保在播放期间使用正确的服务器和内容类型。

安全和签名：

sig=AJfQdSswRgIhAKYSPhT9klkjnENyP9hCXfygk — cDAubSyYcr5BGT25iAiEAh7sqFXG0…：用于验证请求完整性的加密签名，确保URL未被篡改且是真实的。

与 S3 类存储的比较

虽然此 URL 结构与Amazon S3等对象存储服务有相似之处，但它代表了Google 的专有视频基础设施。主要相似之处包括：

自定义域名：`googlevideo.com` 的使用反映了亚马逊的 `s3.amazonaws.com`，提供专门的视频内容传送。
直接媒体访问：与 S3 一样，YouTube 通过 URL 直接提供媒体文件。
安全和参数化访问：’expire’、’id’ 和 ‘sig’ 等参数控制内容访问，类似于 S3 的签名 URL。
优化交付：YouTube 的 CDN 实施与 S3 的 CloudFront 集成并行，以实现高效的内容交付。

该架构展示了 YouTube 在视频流处理方面的先进方法，结合了安全性、高效交付和基于网络条件的自适应流处理。

结论

总而言之，YouTube 的视频流系统完美体现了现代科技的复杂和高效。无论您使用什么设备或互联网连接有多强，URL 和后端流程的每个部分都发挥着确保视频安全流畅地到达您手中的作用。从安全访问令牌到自适应流媒体，YouTube 已经建立了一个可以同时处理数百万用户的基础设施，为我们提供了轻松无忧的体验。

YouTube 系统适应不同网络条件和优化视频传输的方式证明了现代网络技术和内容分发网络 (CDN) 的强大功能。了解这些组件让我们更深刻地理解我们经常认为理所当然的流媒体服务。