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

摘 要：为了探讨多媒体监控系统中所要传输的大量数据，针对CDN网络在进行分发时由于代理服务器存贮空间的有限性而造成应用性能的下降这一特性。利用半同步／半异步的模式进行框架设计，结合任务池和线程池等技术设计和实现了基于P2P，的CDN流媒体系统中媒体资源服务器和原始服务器之间的传输子系统，并提出了基于任务池闲置信息和系统 一运行参数统计信息相结合的有效动态线程池和任务池管理算法。根据各种运行参数信息动态评估系统当前的负载和压力情况，并对任务池和线程池尺寸进行动态修改。通过与两种传统实现方式的实验比较，发现在采用新算法后，显著降低了CPU的负载，有效提高了系统效率和网络吞吐量。
关键词：内容分发网；对等网；半同步／半异步；任务池；线程池

O 引 言
    对等网络P2P(Peer-to-peer)技术是目前国际计算机网络技术领域研究的一个热点。该技术的雏形产生于20世纪70年代，典型代表是UseNet和FidoNet；而CDN内容分发网络(Content Distri-bution Network)则是将网站的内容或媒体发布到最接近用户的网络“边缘”，当用户访问时，系统自动无缝地把用户重定向到边缘服务器，从而减轻中心服务器和主干网络的压力，提升流媒体或网站的性能。
    随着网络技术的迅猛发展，流媒体内容在互联网中大量传播，对于高质量的流媒体分发服务体现得越加明显，因而为大量用户提供快速，高质量的流媒体分发服务成为了最近研究的热点和难点。
    在多媒体监控系统中所要传输的数据量是相当大的，主要包括：控制信息、反馈信息、视频、音频和其他如文本信息等。对于传统的基于C／S模式或B／S模式的多媒体监控系统，在监控点和监控中心之间进行这些大量流媒体数据传输，服务器性能会直线下降。基于此本文把P2P技术引入到该多媒体监控系统设计中主要做了如下改进：
    (1)设计了基于P2P和CDN的监控传输子系统。
    (2)客户利用P2P方式从边缘服务器得到服务，同时原始服务器和边缘服务器之间的内容发布也通过P2P方式进行，通过这种方式有效地利用了系统中网络带宽和主机资源，减轻了原始服务器和边缘服务器的压力，减少了主干网数据流量，降低了运营商的成本，提高了客户的服务质量。
    (3)为了缓解网络I／O和磁盘I／O的矛盾，在传输子系统的设计中采用半同步／半异步的方式将网络I／O与磁盘I／O分开，并通过任务池的方式进行缓冲。
    (4)设计了线程池动态管理算法，有效减小了CPU的负载压力，提高了网络吞吐量和系统整体性能。
    (5)针对传统方式的缺点进行了有效的改进，利用半同步／半异步的方式建立系统框架，利用任务池对数据的读写请求进行封装，采用线程池对任务池中的任务进行高效异步处理。通过对任务的闲置情况进行统计，并结合系统的当前资源利用情况，对任务池和线程池进行动态管理，降低了CPU的负载，提高了系统的吞吐量。

2 系统框架
    系统总体布局如图1所示，边缘服务器将会与若干客户节点形成P2P网络，提供高效的服务质量，便于降低服务器的负载。

    当客户在边缘服务器上请求资源不命中时，边缘服务器会向原始服务器请求，原始服务器会根据具体请求要求，将需要的媒体资源通过该文实现的高效传输子系统存储在本地，然后利用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 三种模型的实验数据
    实验通过传输子系统从负载发生器下载数据来模拟大量数据请求，并分别收集下列三种模型的实验数据：
    (1)传统多线程阻塞模型，即每个现存阻塞得处理一个单独的请求，在图3中用A表示，并简称为A模型。
    (2)固定线程数目的线程池，初试线程数采用CPU个数的2倍加2来确定，即10个初始线程，在图3中用B表示，并简称为B模型。
    (3)采用该文提出的线程池动态管理算法的模型，初试线程个数也为10个，在图3中用C表示，并简称C模型。
4．2 分析数据得平均值
    下面数据均是通过nmon采样和ninon analyser分析得到的平均值。
    (1)CPU使用率比较。从图3中可以看到，在A模型中，基本已经占用了所有的CPU资源。因为每个线程服务一个请求，一旦请求大量到来，就会有大量的线程产生。而在B模型中，因为线程个数固定，且已经预先创建好，当请求量过大时，任务队列会起到很好的缓冲作用。C模型是效果最好的，因为线程个数总是会被调整到最佳的个数，并且任务池的使用有效减少了系统中频繁的内存申请和释放操作。

    (2)空闲内存比较。从图4中可以容易分析得到，当请求的总量相同的情况下，A和B模型占用的内存情况很接近。但是C模型中，任务池和线程池的大小都是动态伸缩的，提高了系统的处理能力，自然也会使用更多的内存。

    (3)网络I／O流量比较。图5展现了3种模型的网络I／O情况，在A模型中，因为采用的是阻塞的方式进行的，当套口已经没有数据可读，线程会阻塞等待数据的到达，而其他已经有数据到达的套接口则可能得不到处理，因此A模型的网络吞吐量比较低。在B模型中，采用的非阻塞和线程池模型，一旦一个套接口将要发生阻塞，线程可以很快切换到其他已经有数据准备好的套接口上，加快了数据的接收速度，因此也提高了网络的传输速度。在C模型中，减小了内存和CPU等部件的负载，提高了性能，动态任务池使得系统有比B模型更好的缓存能力，因此C模型比B模型网络吞吐量更高是可以理解的。系统采用的是l 000 Mb／s网卡，基本达到了网卡的极限。

5 结 语
    根据统计线程池中的各个线程的平均等待时间和当前CPU的使用率，对线程池的尺寸进行动态的调整。利用这种线程池动态管理算法，可以很好地适应Internet上客户请求突发性变化的情况。当突然到来大量请求时，根据算法原理，可以增加适量的线程满足额外的请求；当请求变少以后，会将线程的数量减少，从而减轻系统的压力。经过实验分析比较可以得出，采用线程池动态管理算法之后，有效减小了CPU的负载压力，提高了网络吞吐量和系统整体性能。但是，线程池的管理还有很多地方可以优化，比如调整线程池尺寸都是以2为步长进行调整的，但是这个步长是根据经验得出来的，还没有很好的理论依据。同时，可以增加更多的统计信息加入到算法的决策之中，提高算法的精确性。
    这里实现了在多媒体监控传输系统中P2P和CDN的结合，引入半同步／半异步的模式，设计了系统框架，引入任务池和线程池等技术，解决了媒体资源服务器和原始服务器之间的高效传输子系统的网络瓶颈，设计了有效的线程池动态管理算法。