常见分布式应用系统设计图解（六）：流媒体系统

流媒体系统，主要是视频流媒体系统。比如 YouTube，比如 Netflix，比如爱奇艺，还有优酷。再一个许多大型的社交平台上，几乎是一定要内嵌流媒体服务的，以支持用户上传视频类型的内容。

这类系统我们需要考虑的不只有单纯视频文件的存储和传输，还有文件的编码、解码，和视频截图（比如用作 thumbnail）的生成等等基本功能。

• 视频文件上传、编码、截图这个过程可以说非常消耗资源，因此视频流媒体系统的处理往往和简单的图片分享系统不一样，它的处理要求异步进行。而异步系统就一定要有队列。
• 图中上半部分，用户向 Web Server 发起一个视频上传的请求，实际视频上传通过 Uploading Server 来传到视频存储中。元信息放在 Metadata 数据库中，上传完成后入队列一个要求处理视频的事件。事件经过异步系统处理，包括去重、编码和截图等操作，更新后的视频存放会视频存储系统中，而图片存放到另一个图片的存储系统。编码部分可以考虑编码为多个码率的文件，以满足播放时对于不同网络环境的需求。
• 视频的存储方面，由于视频可能较大，可以选择像 HDFS 这样基于 block 的分布式文件系统。既为了可靠性，又为了提高播放（读取）的性能，引入 replication，也可以为流媒体服务器引入专门的缓存。二者比较起来，磁盘上的 replication 更为重要，因为通常用于缓存的内存的价格比较贵。
• 截图和 thumbnail 这类图片，一般都是小图片，通常读压力比较大，再一个考虑到同一个视频的不同时间点的多张截图往往是需要一起读取，为了提高效率可以使用列数据库。还有一种方式是把同一个视频的多张小的截图合并在一张大图里面存起来（客户端（浏览器）得到这张大图以后再切分成多张小图来提供给用户），如果这样存储的话，也可以选择一些能够容纳文件大小的 KV 数据库。注意有的存储系统带有分块要求，如果文件很小而分块很大，那么就有空间浪费的情况（当然像 Bigtable 这种可以将多个文件的数据合并存储到同一个 block 中，就没有这个问题）。
• 下半部分，用户需要播放视频的时候，客户端和流媒体服务器建立连接。视频和图片也可以来自离用户较近的 CDN 节点。综合比较优劣，UDP 往往要优于 TCP。实际视频播放往往不是下载整个视频，而是一个片段一个片段地下载缓冲，用户也很可能会拖动进度条，而跳过某些片段。
• 流媒体系统很适合和 CDN 配合部署，在视频处理完成后，应当写入一个待分发的 queue（为了避免图中过于杂乱，这部分没有），而有一个 Distribution Service 来读取这样的视频信息，并将视频和图片分发到 CDN 的各个节点上。分发可以是主动的，也可以是被动的（根据用户实际访问的热度）。
• 客户端应当具备解码的能力，也有相应的容错处理。在一个流媒体地址访问失败的情况下，除了重试，还可以具备切换到备用地址的能力。

这是《常见分布式系统设计图解》系列文章中的一篇，如果你感兴趣，请参阅汇总（目录）寻找你其它感兴趣的内容。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》