DVB+OTT終端管理系統(tǒng)的高并發(fā)處理方案

王迪帥，張 儒，王志謙

(北京郵電大學(xué) 網(wǎng)絡(luò)技術(shù)研究院 信息網(wǎng)絡(luò)中心，北京 100876)

?

DVB+OTT終端管理系統(tǒng)的高并發(fā)處理方案

王迪帥，張 儒，王志謙

(北京郵電大學(xué) 網(wǎng)絡(luò)技術(shù)研究院 信息網(wǎng)絡(luò)中心，北京 100876)

介紹了一種基于TR069協(xié)議(CPE廣域網(wǎng)管理協(xié)議)的DVB/OTT終端管理系統(tǒng)的高并發(fā)處理方案。通過(guò)設(shè)置緩存區(qū)、使用線程池、設(shè)置終端開(kāi)機(jī)延遲3個(gè)方面優(yōu)化系統(tǒng)，可以有效地解決大規(guī)模的機(jī)頂盒終端同一時(shí)刻向終端管理系統(tǒng)發(fā)送請(qǐng)求而引起的高并發(fā)問(wèn)題，從而保證終端管理系統(tǒng)能夠在高并發(fā)環(huán)境下穩(wěn)定運(yùn)行。

TR069協(xié)議；機(jī)頂盒；終端管理；高并發(fā)

隨著寬帶網(wǎng)絡(luò)技術(shù)的發(fā)展，家庭網(wǎng)絡(luò)設(shè)備呈現(xiàn)出高度分散、規(guī)模大、種類(lèi)多、業(yè)務(wù)復(fù)雜化等特點(diǎn)。依靠技術(shù)人員上門(mén)服務(wù)及時(shí)性差、成本高，而終端管理系統(tǒng)可以改變這種現(xiàn)狀，實(shí)現(xiàn)設(shè)備的遠(yuǎn)程管理。DVB/OTT雙模終端是廣電運(yùn)營(yíng)商為適應(yīng)三網(wǎng)融合趨勢(shì)而發(fā)展的一類(lèi)新型終端，但是目前國(guó)內(nèi)廣電運(yùn)營(yíng)商尚未部署相應(yīng)的管理系統(tǒng)。電信運(yùn)營(yíng)商在終端管理實(shí)踐中多采用以TR069協(xié)議(CPE廣域網(wǎng)管理協(xié)議)為基礎(chǔ)的技術(shù)管理體制，并且取得了很好的效果[1-6]。

在客戶終端設(shè)備(Customer Premise Equipment，CPE，本文指機(jī)頂盒)與自動(dòng)配置服務(wù)器(Auto Configuration Server，ACS，即終端管理系統(tǒng))交互的過(guò)程中，由于終端設(shè)備的數(shù)量巨大、上報(bào)頻繁等因素，系統(tǒng)必須能夠應(yīng)對(duì)大規(guī)模終端設(shè)備引發(fā)的高并發(fā)情形。本文提出了一套解決終端管理系統(tǒng)大規(guī)模、高并發(fā)等關(guān)鍵技術(shù)問(wèn)題的處理方案，使得該系統(tǒng)在高并發(fā)環(huán)境下具有穩(wěn)定性、可用性。

1 系統(tǒng)的高并發(fā)處理方案

1.1 引起高并發(fā)問(wèn)題的原因

CPE與ACS交互的過(guò)程中，因?yàn)槟承┦录穷l繁發(fā)生的，如開(kāi)機(jī)上報(bào)、周期上報(bào)等，這些情況會(huì)使得CPE主動(dòng)向ACS發(fā)送請(qǐng)求。因此，CPE與ACS的交互幾乎時(shí)刻都在發(fā)生，當(dāng)CPE達(dá)到一定的數(shù)量規(guī)模時(shí),ACS需要進(jìn)行大量的I/O操作，并且還需要產(chǎn)生回應(yīng)報(bào)文返回給CPE。這種情況很容易對(duì)ACS的性能和響應(yīng)速度造成影響，甚至導(dǎo)致系統(tǒng)的崩潰。

根據(jù)系統(tǒng)的特點(diǎn)，本文從3個(gè)方面來(lái)解決終端管理系統(tǒng)高并發(fā)的問(wèn)題，設(shè)置緩存區(qū)、使用線程池、設(shè)置終端開(kāi)機(jī)延遲。

1.2 設(shè)置緩存區(qū)

1.2.1 緩存區(qū)設(shè)計(jì)

CPE與ACS交互的過(guò)程中，獲取參數(shù)、設(shè)置參數(shù)等事件發(fā)生的頻率較小，相反一些事件幾乎時(shí)刻都在發(fā)生。這類(lèi)事件頻繁發(fā)生并且CPE規(guī)模較大，正是產(chǎn)生高并發(fā)問(wèn)題的重要原因。而ACS對(duì)這些事件的回應(yīng)數(shù)據(jù)基本相同，因此可以將對(duì)這些事件的回應(yīng)數(shù)據(jù)放入緩存區(qū)中。

當(dāng)大規(guī)模的CPE同時(shí)向ACS發(fā)出請(qǐng)求時(shí)，首先需要判斷請(qǐng)求的類(lèi)型，并根據(jù)請(qǐng)求的類(lèi)型決定是否需要重新生成新的響應(yīng)報(bào)文。如果該請(qǐng)求屬于頻繁事件范疇，直接取出緩存區(qū)的相應(yīng)數(shù)據(jù)回應(yīng)CPE。在CPE的IP地址未改變的情況下，并不需要ACS更新數(shù)據(jù)庫(kù)和產(chǎn)生新的SOAP RPC回應(yīng)報(bào)文。這樣可以減少ACS大量操作數(shù)據(jù)庫(kù)及生成新報(bào)文的開(kāi)銷(xiāo)，系統(tǒng)的處理性能顯著提升。這個(gè)過(guò)程的流程圖如圖1所示。

圖1 ACS響應(yīng)的過(guò)程

緩存區(qū)的結(jié)構(gòu)設(shè)計(jì)：由于緩存區(qū)只需要存儲(chǔ)頻繁事件的類(lèi)型以及相應(yīng)的回應(yīng)報(bào)文，因此可以選用HashMap來(lái)實(shí)現(xiàn)。但HashMap不是線程安全的，在多線程操作中容易出現(xiàn)問(wèn)題。本文選擇ConcurrentHashMap來(lái)實(shí)現(xiàn)緩存區(qū)，它是線程安全的，其內(nèi)部實(shí)現(xiàn)細(xì)節(jié)這里不再贅述。ConcurrentHashMap位于java.util.concurrent中。主要代碼如下：

Mapcache=new ConcurrentHashMap();

cache.put("頻繁事件類(lèi)型","回應(yīng)報(bào)文");//將報(bào)文事先放入緩存區(qū)

當(dāng)CPE向ACS發(fā)出請(qǐng)求時(shí)，首先判斷請(qǐng)求的類(lèi)型，如果該請(qǐng)求屬于頻繁事件范疇，直接取出緩存區(qū)中的相應(yīng)數(shù)據(jù)回應(yīng)CPE，代碼如下：

String response=cache.get("頻繁事件類(lèi)型");

response即為回應(yīng)報(bào)文的內(nèi)容，因此ACS不必再次生成新的報(bào)文回復(fù)CPE。

1.2.2 數(shù)據(jù)庫(kù)的優(yōu)化

設(shè)置緩存區(qū)的目的是盡量減少對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)以及避免生成新的回應(yīng)報(bào)文。然而，很多時(shí)候?qū)?shù)據(jù)庫(kù)的訪問(wèn)無(wú)法避免，因此，本文從數(shù)據(jù)庫(kù)連接和查詢兩個(gè)方面來(lái)優(yōu)化數(shù)據(jù)庫(kù)。

系統(tǒng)采用EJB規(guī)范中的JPA(Java Persistence API)來(lái)實(shí)現(xiàn)數(shù)據(jù)持久化操作，通過(guò)mysql-ds.xml配置數(shù)據(jù)源及數(shù)據(jù)庫(kù)連接池的相關(guān)信息。此外，通過(guò)建立合理的索引來(lái)提高查詢效率。這里以采集信息模塊為例，其在數(shù)據(jù)庫(kù)中對(duì)應(yīng)cpeInfo表，表中共有4個(gè)字段:id,event,time,sn(id號(hào)，事件類(lèi)型，時(shí)間，機(jī)頂盒唯一編號(hào))，其中id為自增字段。本文使用event,time,sn這3個(gè)字段的組合索引，SQL語(yǔ)句如下：

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

1.3 使用線程池

系統(tǒng)采用多線程技術(shù)來(lái)解決ACS的并發(fā)訪問(wèn)。本文的多線程方案是建立在線程池的基礎(chǔ)之上的，具體的工作流程如圖2所示。

圖2 線程池的工作過(guò)程

本文采用JDK實(shí)現(xiàn)的線程池，位于java.util.concurrent.Executors類(lèi)中，使用public static ExecutorService newCachedThreadPool()方法可以創(chuàng)建一個(gè)new Cached Thread Pool線程池，它是可動(dòng)態(tài)擴(kuò)展的。從圖2也可以看出，線程池的大小會(huì)根據(jù)任務(wù)規(guī)模做出相應(yīng)的調(diào)整，以節(jié)省系統(tǒng)資源。下文是使用線程池的關(guān)鍵代碼：

ExecutorService es=Executors.newCachedThreadPool();//創(chuàng)建線程池

Runnabler=new Runnable(){ //創(chuàng)建一個(gè)Runnable對(duì)象

public void run(){} //重寫(xiě)run方法

}

es.execute(r); //向線程池提交任務(wù)

1.4 設(shè)置終端開(kāi)機(jī)延遲

設(shè)置終端開(kāi)機(jī)延遲是從終端的角度解決高并發(fā)問(wèn)題。考慮到某些特殊情況引起的高并發(fā)情形，例如小區(qū)突然停電，再次供電時(shí)，整個(gè)小區(qū)的機(jī)頂盒在同一時(shí)刻啟動(dòng)并發(fā)送開(kāi)機(jī)報(bào)文。如果這種情形發(fā)生于多個(gè)小區(qū)，將會(huì)產(chǎn)生巨大的并發(fā)量。因此，可以在機(jī)頂盒實(shí)現(xiàn)規(guī)范中添加一項(xiàng)規(guī)定：機(jī)頂盒每次開(kāi)機(jī)以后，不立即發(fā)送開(kāi)機(jī)報(bào)文，而是產(chǎn)生一個(gè)隨機(jī)數(shù)作為延遲發(fā)送的時(shí)間。如果遇到上述情況時(shí)，雖然所有的機(jī)頂盒在再次供電后會(huì)同時(shí)啟動(dòng)，但是由于每臺(tái)機(jī)頂盒都會(huì)延遲一個(gè)隨機(jī)的時(shí)間后才發(fā)送開(kāi)機(jī)報(bào)文，這樣就可以大大減少并發(fā)量，從而避免上述情況下遭遇的巨大并發(fā)量的問(wèn)題。過(guò)程如圖3所示。

圖3 開(kāi)機(jī)延遲過(guò)程

其中，獲取隨機(jī)數(shù)可以采取以下方式：

(強(qiáng)制類(lèi)型轉(zhuǎn)換)(MIN+Math.random()*(MAX-MIN+1))

MAX是隨機(jī)數(shù)最大值，MIN是隨機(jī)數(shù)最小值。例如獲取1到10(包括兩端)的int型隨機(jī)數(shù)為：

(int)(1+Math.random()*(10-1+1))其中，Math.random()方法位于java.lang.Math中，它是一個(gè)可以產(chǎn)生[0.0,1.0]區(qū)間內(nèi)的雙精度浮點(diǎn)數(shù)的方法。

機(jī)頂盒開(kāi)機(jī)后隨機(jī)延遲0～10 000 ms(含兩端)發(fā)送開(kāi)機(jī)報(bào)文，根據(jù)上述獲取隨機(jī)數(shù)的方法為：

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

r即為延遲時(shí)間(單位：ms)。

每臺(tái)機(jī)頂盒在開(kāi)機(jī)后延遲r的時(shí)間，再向ACS發(fā)送開(kāi)機(jī)報(bào)文，由于隨機(jī)數(shù)的重復(fù)率非常低，因此可以大大降低并發(fā)量。

2 測(cè)試結(jié)果

ACS系統(tǒng)部署環(huán)境：CentOS6.5+jboss4.2+MYSQL5.5，使用loadRunner11做壓力測(cè)試。本次測(cè)試模擬3 000臺(tái)客戶端同時(shí)向ACS發(fā)送請(qǐng)求，觀測(cè)ACS的響應(yīng)時(shí)間和Linux系統(tǒng)的資源使用情況。整體來(lái)看，系統(tǒng)在3 000臺(tái)CPE環(huán)境下性能穩(wěn)定。從圖4可以看出，最大響應(yīng)時(shí)間是0.805 s，最小是0.039 s，平均僅為0.106 s。圖5為響應(yīng)時(shí)間分布曲線。圖6表明Linux系統(tǒng)的各項(xiàng)資源使用率均處于安全范圍內(nèi)，系統(tǒng)較穩(wěn)定。

圖4 響應(yīng)時(shí)間匯總(截圖)

圖5 響應(yīng)時(shí)間分布曲線(截圖)

圖6 Linux系統(tǒng)的資源使用情況(截圖)

3 本方案優(yōu)勢(shì)

現(xiàn)存的終端管理系統(tǒng)很少有專(zhuān)門(mén)考慮高并發(fā)情形并給出實(shí)際處理方案的。本文針對(duì)這一問(wèn)題提出了處理方案，并且在實(shí)際環(huán)境中做了壓力測(cè)試，證明此方案確實(shí)是有效可行的。

當(dāng)前，國(guó)內(nèi)外主要采取下面幾種方式來(lái)處理高并發(fā)問(wèn)題：使用更高性能的硬件、集群化以及軟件方面優(yōu)化(如生成靜態(tài)頁(yè)面)等。對(duì)于通過(guò)硬件來(lái)提升系統(tǒng)性能，這里不做對(duì)比，集群化也需要大量的硬件，這里只對(duì)比單機(jī)的情況，下面通過(guò)對(duì)比單機(jī)軟件方面的優(yōu)化來(lái)突出本方案的優(yōu)勢(shì)。

1)本系統(tǒng)是基于B/S結(jié)構(gòu)的，B/S結(jié)構(gòu)比較常用的高并發(fā)處理方案是生成靜態(tài)頁(yè)面。但本系統(tǒng)的用戶端并不是瀏覽器，而是機(jī)頂盒，不需要服務(wù)器返回頁(yè)面給用戶，因此此方案不適用于本系統(tǒng)。本方案根據(jù)系統(tǒng)的特點(diǎn)，使用緩存區(qū)來(lái)完成對(duì)客戶端數(shù)據(jù)的快速處理和回應(yīng)，達(dá)到了類(lèi)似的效果。

2)使用線程池來(lái)解決高并發(fā)問(wèn)題也是現(xiàn)有終端管理系統(tǒng)普遍會(huì)采用的方法，但是考慮到終端數(shù)量的不斷遞增，使用普通的線程池已經(jīng)無(wú)法滿足要求。本方案使用的可緩存線程池newCachedThreadPool可以根據(jù)終端數(shù)量實(shí)時(shí)調(diào)整線程池的大小，真正做到了系統(tǒng)的可伸縮性和可擴(kuò)展性。

3)在與數(shù)據(jù)庫(kù)的交互中，本文采用EJB中的JPA，能夠直接持久化復(fù)雜的Java對(duì)象，并且通過(guò)JPQL查詢數(shù)據(jù)，JPA操作起來(lái)比ORM要方便。表1是幾種數(shù)據(jù)庫(kù)操作方式對(duì)比。

表1 幾種數(shù)據(jù)庫(kù)操作方式對(duì)比

4)本方案不僅從服務(wù)器端考慮問(wèn)題，同時(shí)也從終端的角度出發(fā)，終端開(kāi)機(jī)之后自動(dòng)延遲隨機(jī)時(shí)間再上報(bào)信息。二者結(jié)合對(duì)于整個(gè)系統(tǒng)的性能提升有更明顯的效果。

4 結(jié)束語(yǔ)

本文提出了基于TR069協(xié)議的終端管理系統(tǒng)的高并發(fā)處理方案。介紹了終端管理系統(tǒng)(ACS)與用戶終端(CPE)的交互過(guò)程，分析并闡述了產(chǎn)生高并發(fā)問(wèn)題的原因，進(jìn)而提出了高并發(fā)問(wèn)題的處理方案。整個(gè)方案分為3個(gè)方面，其中使用緩存區(qū)和使用線程池是以ACS端為出發(fā)點(diǎn)，而設(shè)置開(kāi)機(jī)延遲是從用戶終端的角度解決高并發(fā)問(wèn)題。經(jīng)過(guò)測(cè)試，上述處理方案能明顯改善系統(tǒng)的性能，使系統(tǒng)能在高并發(fā)環(huán)境下穩(wěn)定運(yùn)行，達(dá)到了預(yù)期的效果。

[1]盛川.基于TR-069協(xié)議的自動(dòng)配置服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)[D].上海：復(fù)旦大學(xué),2010.

[3]馮素曉.高校人事檔案的信息化建設(shè)探究——索引的選擇與應(yīng)用[J].軟件導(dǎo)刊，2011，10(10)：78-80.

[4]劉新強(qiáng),曾兵義.用線程池解決服務(wù)器并發(fā)請(qǐng)求的方案設(shè)計(jì)[J].現(xiàn)代電子技術(shù)，2011，34(15)：141-143.DOI:10.3969/j.issn.1004-373X.2011.15.041.

[5]許永達(dá).基于線程池的高并發(fā)訪問(wèn)考試系統(tǒng)設(shè)計(jì)[J].計(jì)算機(jī)與現(xiàn)代化，2013(3)：232-234,238.DOI:10.3969/j.issn.1006-2475.2013.03.060.

[6]彭玉柱，孟凡超，初佃輝，等.基于多線程機(jī)制的電力數(shù)據(jù)采集系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用與軟件，2015，32(1)：78-81.DOI:10.3969/j.issn.1000-386x.2015.01.020.

王迪帥，碩士生，主研網(wǎng)絡(luò)技術(shù)與應(yīng)用；

張 儒，女，碩士生，主研網(wǎng)絡(luò)技術(shù)與應(yīng)用；

王志謙，高級(jí)工程師，主要研究方向?yàn)閺V播電視綜合服務(wù)網(wǎng)絡(luò)。

責(zé)任編輯：許 盈

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終端管理系統(tǒng)的高并發(fā)處理方案[J].電視技術(shù)，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協(xié)議的網(wǎng)管系統(tǒng)的研究[D].北京：華北電力大學(xué),2011.

10.7666/d.y1954281.

2016-03-25