基于P2P和CDN的监控传输子系统的设计

当客户在边缘服务器上请求资源不命中时，边缘服务器会向原始服务器请求，原始服务器会根据具体请求要求，将需要的媒体资源通过该文实现的高效传输子系统存储在本地，然后利用P2P的方式向多个边缘服务器发布内容。
通过这种方式有效减轻了原始服务器在内容发布时的压力。理论上它只要将一个完整的媒体副本发送出去，其他边缘服务器会根据P2P的方式得到一个完整的副本。同理，当边缘服务器向客户提供服务时，理论上它也只需要传输一个副本，多个客户端就可以得到完整的服务。原始服务器和媒体资源服务器通常是在一个子网中，网络速度比磁盘I／O速度更快。此时，磁盘I／O成了系统的瓶颈。为了缓解网络I／O和磁盘1／O的矛盾，在传输子系统的设计当中采用半同步／半异步的方式将网络I／O与磁盘I／O分离开，并通过任务池的方式进行缓冲。
上层的主线程处理epoll异步事件和协议交互，框架将接收到的数据按照固定大小封装在任务里面，然后将任务放回任务池，下层线程池负责从任务池中取出任务，进行具体的磁盘读写操作，操作完成后线程和任务分别回到线程池和任务池等待调度。

3 算法实现
为了对线程池进行有效的动态管理，需要采集各种性能参数，经过综合分析之后，对线程池做出调整。该算法中参考了两个最关键的参数，即任务的平均等待时间和CPU使用率。通过任务的平均等待时间，可以分析得到当前线程池需要调整的方向。通过CPU使用率可以得到是否需要增加或者减少线程。

图2中c(current)表示线程池当前平均等待时间；p(previous)表示线程池上次等待时间；pp表示上上次等待时间；ps(pool size)表示线程池大小；pps表示上次线程池大小。该算法中并不是对等待时间的绝对值进行比较，而是对currTime和preTime进行比较，如果差异大于1％，线程池可能需要调整，调整方向需要根据currTime和preTime的大小关系来决定。如果currTime大于preTime，需要进一步比较pre-Time和prepreTime的关系；如果preTime小于prepreTime，并且CPU使用率大于90％，那么减小线程池。减小的步长(stride)为2。如果preTime大于prepreTime，并且CPU使用率小于80％，则增大线程池，增加的步长为2。如果currTime小于preTime，并且preTime小于prepreTime，则增大线程池。
简而言之，算法通过对currTime，preTime，prepre-
Time三者的关系进行比较，确定线程池是否需要调整。
当需要减小线程池时，需要进一步判断CPU的使用率，只有CPU大于一个阀值时才进行减小操作，因为CPU的负载太小也是一种资源浪费；同理，当需要增大线程池时，也只能在CPU小于一个阀值时，才能进行增加操作，因为CPU的负载不能过大。

4 实验分析
因为媒体资源服务器和原始服务器多在同一个子网中，因此实验的环境也通过一个局域网模拟，服务器的基本配置是：两个Intel双核Xeon 3 GHz芯片、2 048 KB缓存、4 GB内存、1 000 Mb／s网卡。
4．1 三种模型的实验数据