DVB+OTT终端管理系统的高并发处理方案

王迪帅，张 儒，王志谦

(北京邮电大学 网络技术研究院 信息网络中心，北京 100876)



DVB+OTT终端管理系统的高并发处理方案

王迪帅，张 儒，王志谦

(北京邮电大学 网络技术研究院 信息网络中心，北京 100876)

介绍了一种基于TR069协议(CPE广域网管理协议)的DVB/OTT终端管理系统的高并发处理方案。通过设置缓存区、使用线程池、设置终端开机延迟3个方面优化系统，可以有效地解决大规模的机顶盒终端同一时刻向终端管理系统发送请求而引起的高并发问题，从而保证终端管理系统能够在高并发环境下稳定运行。

TR069协议；机顶盒；终端管理；高并发

随着宽带网络技术的发展，家庭网络设备呈现出高度分散、规模大、种类多、业务复杂化等特点。依靠技术人员上门服务及时性差、成本高，而终端管理系统可以改变这种现状，实现设备的远程管理。DVB/OTT双模终端是广电运营商为适应三网融合趋势而发展的一类新型终端，但是目前国内广电运营商尚未部署相应的管理系统。电信运营商在终端管理实践中多采用以TR069协议(CPE广域网管理协议)为基础的技术管理体制，并且取得了很好的效果[1-6]。

在客户终端设备(Customer Premise Equipment，CPE，本文指机顶盒)与自动配置服务器(Auto Configuration Server，ACS，即终端管理系统)交互的过程中，由于终端设备的数量巨大、上报频繁等因素，系统必须能够应对大规模终端设备引发的高并发情形。本文提出了一套解决终端管理系统大规模、高并发等关键技术问题的处理方案，使得该系统在高并发环境下具有稳定性、可用性。

1 系统的高并发处理方案

1.1 引起高并发问题的原因

CPE与ACS交互的过程中，因为某些事件是频繁发生的，如开机上报、周期上报等，这些情况会使得CPE主动向ACS发送请求。因此，CPE与ACS的交互几乎时刻都在发生，当CPE达到一定的数量规模时,ACS需要进行大量的I/O操作，并且还需要产生回应报文返回给CPE。这种情况很容易对ACS的性能和响应速度造成影响，甚至导致系统的崩溃。

根据系统的特点，本文从3个方面来解决终端管理系统高并发的问题，设置缓存区、使用线程池、设置终端开机延迟。

1.2 设置缓存区

1.2.1 缓存区设计

CPE与ACS交互的过程中，获取参数、设置参数等事件发生的频率较小，相反一些事件几乎时刻都在发生。这类事件频繁发生并且CPE规模较大，正是产生高并发问题的重要原因。而ACS对这些事件的回应数据基本相同，因此可以将对这些事件的回应数据放入缓存区中。

当大规模的CPE同时向ACS发出请求时，首先需要判断请求的类型，并根据请求的类型决定是否需要重新生成新的响应报文。如果该请求属于频繁事件范畴，直接取出缓存区的相应数据回应CPE。在CPE的IP地址未改变的情况下，并不需要ACS更新数据库和产生新的SOAP RPC回应报文。这样可以减少ACS大量操作数据库及生成新报文的开销，系统的处理性能显著提升。这个过程的流程图如图1所示。

图1 ACS响应的过程

缓存区的结构设计：由于缓存区只需要存储频繁事件的类型以及相应的回应报文，因此可以选用HashMap来实现。但HashMap不是线程安全的，在多线程操作中容易出现问题。本文选择ConcurrentHashMap来实现缓存区，它是线程安全的，其内部实现细节这里不再赘述。ConcurrentHashMap位于java.util.concurrent中。主要代码如下：

Mapcache=new ConcurrentHashMap();

cache.put("频繁事件类型","回应报文");//将报文事先放入缓存区

当CPE向ACS发出请求时，首先判断请求的类型，如果该请求属于频繁事件范畴，直接取出缓存区中的相应数据回应CPE，代码如下：

String response=cache.get("频繁事件类型");

response即为回应报文的内容，因此ACS不必再次生成新的报文回复CPE。

1.2.2 数据库的优化

设置缓存区的目的是尽量减少对数据库的访问以及避免生成新的回应报文。然而，很多时候对数据库的访问无法避免，因此，本文从数据库连接和查询两个方面来优化数据库。

系统采用EJB规范中的JPA(Java Persistence API)来实现数据持久化操作，通过mysql-ds.xml配置数据源及数据库连接池的相关信息。此外，通过建立合理的索引来提高查询效率。这里以采集信息模块为例，其在数据库中对应cpeInfo表，表中共有4个字段:id,event,time,sn(id号，事件类型，时间，机顶盒唯一编号)，其中id为自增字段。本文使用event,time,sn这3个字段的组合索引，SQL语句如下：

ALTER TABLE cpeInfo ADD INDEX event_time_sn (event,time,sn);

1.3 使用线程池

系统采用多线程技术来解决ACS的并发访问。本文的多线程方案是建立在线程池的基础之上的，具体的工作流程如图2所示。

图2 线程池的工作过程

本文采用JDK实现的线程池，位于java.util.concurrent.Executors类中，使用public static ExecutorService newCachedThreadPool()方法可以创建一个new Cached Thread Pool线程池，它是可动态扩展的。从图2也可以看出，线程池的大小会根据任务规模做出相应的调整，以节省系统资源。下文是使用线程池的关键代码：

ExecutorService es=Executors.newCachedThreadPool();//创建线程池

Runnabler=new Runnable(){ //创建一个Runnable对象

public void run(){} //重写run方法

}

es.execute(r); //向线程池提交任务

1.4 设置终端开机延迟

设置终端开机延迟是从终端的角度解决高并发问题。考虑到某些特殊情况引起的高并发情形，例如小区突然停电，再次供电时，整个小区的机顶盒在同一时刻启动并发送开机报文。如果这种情形发生于多个小区，将会产生巨大的并发量。因此，可以在机顶盒实现规范中添加一项规定：机顶盒每次开机以后，不立即发送开机报文，而是产生一个随机数作为延迟发送的时间。如果遇到上述情况时，虽然所有的机顶盒在再次供电后会同时启动，但是由于每台机顶盒都会延迟一个随机的时间后才发送开机报文，这样就可以大大减少并发量，从而避免上述情况下遭遇的巨大并发量的问题。过程如图3所示。

图3 开机延迟过程

其中，获取随机数可以采取以下方式：

(强制类型转换)(MIN+Math.random()*(MAX-MIN+1))

MAX是随机数最大值，MIN是随机数最小值。例如获取1到10(包括两端)的int型随机数为：

(int)(1+Math.random()*(10-1+1))其中，Math.random()方法位于java.lang.Math中，它是一个可以产生[0.0,1.0]区间内的双精度浮点数的方法。

机顶盒开机后随机延迟0～10 000 ms(含两端)发送开机报文，根据上述获取随机数的方法为：

int r=(int)(Math.random()*10001)

r即为延迟时间(单位：ms)。

每台机顶盒在开机后延迟r的时间，再向ACS发送开机报文，由于随机数的重复率非常低，因此可以大大降低并发量。

2 测试结果

ACS系统部署环境：CentOS6.5+jboss4.2+MYSQL5.5，使用loadRunner11做压力测试。本次测试模拟3 000台客户端同时向ACS发送请求，观测ACS的响应时间和Linux系统的资源使用情况。整体来看，系统在3 000台CPE环境下性能稳定。从图4可以看出，最大响应时间是0.805 s，最小是0.039 s，平均仅为0.106 s。图5为响应时间分布曲线。图6表明Linux系统的各项资源使用率均处于安全范围内，系统较稳定。

图4 响应时间汇总(截图)

图5 响应时间分布曲线(截图)

图6 Linux系统的资源使用情况(截图)

3 本方案优势

现存的终端管理系统很少有专门考虑高并发情形并给出实际处理方案的。本文针对这一问题提出了处理方案，并且在实际环境中做了压力测试，证明此方案确实是有效可行的。

当前，国内外主要采取下面几种方式来处理高并发问题：使用更高性能的硬件、集群化以及软件方面优化(如生成静态页面)等。对于通过硬件来提升系统性能，这里不做对比，集群化也需要大量的硬件，这里只对比单机的情况，下面通过对比单机软件方面的优化来突出本方案的优势。

1)本系统是基于B/S结构的，B/S结构比较常用的高并发处理方案是生成静态页面。但本系统的用户端并不是浏览器，而是机顶盒，不需要服务器返回页面给用户，因此此方案不适用于本系统。本方案根据系统的特点，使用缓存区来完成对客户端数据的快速处理和回应，达到了类似的效果。

2)使用线程池来解决高并发问题也是现有终端管理系统普遍会采用的方法，但是考虑到终端数量的不断递增，使用普通的线程池已经无法满足要求。本方案使用的可缓存线程池newCachedThreadPool可以根据终端数量实时调整线程池的大小，真正做到了系统的可伸缩性和可扩展性。

3)在与数据库的交互中，本文采用EJB中的JPA，能够直接持久化复杂的Java对象，并且通过JPQL查询数据，JPA操作起来比ORM要方便。表1是几种数据库操作方式对比。

表1 几种数据库操作方式对比

4)本方案不仅从服务器端考虑问题，同时也从终端的角度出发，终端开机之后自动延迟随机时间再上报信息。二者结合对于整个系统的性能提升有更明显的效果。

4 结束语

本文提出了基于TR069协议的终端管理系统的高并发处理方案。介绍了终端管理系统(ACS)与用户终端(CPE)的交互过程，分析并阐述了产生高并发问题的原因，进而提出了高并发问题的处理方案。整个方案分为3个方面，其中使用缓存区和使用线程池是以ACS端为出发点，而设置开机延迟是从用户终端的角度解决高并发问题。经过测试，上述处理方案能明显改善系统的性能，使系统能在高并发环境下稳定运行，达到了预期的效果。

[1]盛川.基于TR-069协议的自动配置服务的设计与实现[D].上海：复旦大学,2010.

[3]冯素晓.高校人事档案的信息化建设探究——索引的选择与应用[J].软件导刊，2011，10(10)：78-80.

[4]刘新强,曾兵义.用线程池解决服务器并发请求的方案设计[J].现代电子技术，2011，34(15)：141-143.DOI:10.3969/j.issn.1004-373X.2011.15.041.

[5]许永达.基于线程池的高并发访问考试系统设计[J].计算机与现代化，2013(3)：232-234,238.DOI:10.3969/j.issn.1006-2475.2013.03.060.

[6]彭玉柱，孟凡超，初佃辉，等.基于多线程机制的电力数据采集系统设计与实现[J].计算机应用与软件，2015，32(1)：78-81.DOI:10.3969/j.issn.1000-386x.2015.01.020.

王迪帅，硕士生，主研网络技术与应用；

张 儒，女，硕士生，主研网络技术与应用；

王志谦，高级工程师，主要研究方向为广播电视综合服务网络。

责任编辑：许 盈

Solution of dealing with high concurrency of DVB&OTT CPE management system

WANG Dishuai, ZHANG Ru, WANG Zhiqian

(NetworkInformationCenter,NetworkTechnologyResearchInstitute,BeijingUniversityofPostsandTelecommunications,Beijing100876,China)

A solution of dealing with the high concurrency of DVB/OTT CPE management system is introduced based on TR069 protocol.To optimize system by setting cache, using thread pool,setting the CPE boot delay,this way can effectively solve the high concurrency issue that a large number of CPE send a request to the CPE management system at the same time. Thus ensuring the stability of CPE management system under the environment of high concurrency.

TR069 protocol; STB; CPE management; high concurrency

王迪帅，张儒，王志谦.DVB+OTT终端管理系统的高并发处理方案[J].电视技术，2016，40(11)：43-46. WANG D S, ZHANG R, WANG Z Q. Solution of dealing with high concurrency of DVB&OTT CPE management system[J].Video engineering，2016，40(11)：43-46.

TN949.19

A DOI：10.16280/j.videoe.2016.11.009

��艳.基于TR069协议的网管系统的研究[D].北京：华北电力大学,2011.

10.7666/d.y1954281.

2016-03-25