聊聊CDN与高性能流媒体服务器的关键技术设计 _CDN

流媒体服务器的性能可以从抗抖动能力、拥塞率和卡顿率等方面进行分析。当用户访问的频率过高或者并发的数量超过流媒体服务器所能承受的范围时，必须考虑通过限流来保证接口的可用性，从而防止出现因请求数量过多、压力过大造成服务器瘫痪等现象。因此，怎样提高流媒体服务器的抗抖动能力，平滑发送流量，降低卡顿率，减少丢包率是本文描述的重点。

1.流媒体服务器框架设计
前面的CDN的文章对一些相关算法进行了比较分析，对CDN流媒体的关键技术也进行了选取。本文就基于Nginx 服务器，结合 HLS 流媒体协议与令牌桶算法，针对流媒体服务器的数据处理模块、缓存模块与发送模块进行设计。

文章插图

流媒体服务器的数据处理逻辑可分为以下几个部分：
(1) 数据处理模块:
数据处理模块主要负责以下几个功能:
(a) 接收来自客户端的请求和来自上级服务器的发送数据。
(b) 负责数据代理转发，在本地没有直播缓存数据时，需要向上级 CDN 或者源站发送请求从而获取数据，再把数据转发给客户端。
(c) 将录制频道的直播流文件写入存储系统，支持回看功能。

(2) 缓存模块（Cache 模块）:Cache模块用来从磁盘或者内存中读取实体文件，解析出文件码率，分包后对数据包进行时戳标记，并将标记好时戳的数据包压入数据发送模块。
(3) 发送模块（Shaper 模块）:Shaper 模块的主要功能是将 Cache 模块输入的数据发送至客户端。Shaper 模块在进行数据处理时会根据当前的发送状态控制发送速率。Shaper 模块中的队列提供 FIFO（先进先出）的数据重传功能，保证数据在重传时不会乱序。流媒体服务器框架设计结构图如下所示:

文章插图

数据处理模块在收到来自客户端的请求后，会根据请求内容从 Cache 模块中寻找相应资源，如果 Cache 模块有相应的资源，则直接将数据交由 Shaper 模块进行发送处理；如果 Cache 模块中没有相应资源，则会主动到本地磁盘进行资源查找；如果本地磁盘也没有相应资源，则会通过数据处理模块向源站发送请求信息，数据处理模块接收源站的相应数据并将数据存放在存储服务器中，最终 Shaper 模块负责将用户所请求的内容返回给客户端。有时，对于一些热门的视频业务，数据处理模块会提前向源站请求资源存入存储服务器中，当用户请求到来时可以及时作出响应。

2.流媒体服务器数据处理模块设计
2.1 数据接收和转发模块设计与实现
在处理多客户端请求时，可以在服务器端创建多个进程，但这种做法显然有一些弊端，创建进程本身是一个消耗计算机资源的过程，一味地创建进程也无法应对快速发展的业务量。I/O 多路复用技术让一个进程可以处理多个客户端需求，使得上述问题得以解决。这里也会涉及到很多优化，所以我们需要考虑到可以使用更优秀的商用框架。
I/O 多路复用技术可以理解为通过一种机制来监视多个文件描述符（文件描述符是计算机术语，用来表示指向文件的引用），当某个描述符就绪，对程序进行相应通知来完成读写操作。在 I/O 多路复用的解决方案中，有 select、poll 和 epoll 三种方式，这三种方式的本质都是同步 I/O 。当然也可以做到异步。
epoll 模型不仅会告知应用程序有 I/O 时间到来，还会告知 I/O 流的相关信息，因此，应用程序不必遍历整个文件描述符集合就能定位到 I/O 事件，其时间复杂度为 O(1) 。在性能上，select 模型和 poll 模型都会随着连接数的增加性能急剧下降，而 epoll 模型在处理成千上万的并发时，性能没有很大的改变，且其对连接数上限没有限制。epoll 模型最大的优点在于它只关心活跃的连接，而不关心总连接数，因此在实际的网络环境中，epoll 的效率远超于 select 模型与 poll 模型。epoll 除了在开发复杂度上略有难度，在内部使用数据结构、内核空间以及内在处理文件描述符机制等方面都优于 select，最重要的是，epoll 是实现了高并发的基础。select、poll 与 epoll比较如下图所示: