黃天天 ,劉 波 , 2, 3
(1.湖南農業大學信息科學技術學院,湖南 長沙 410128;2.邵陽學院湘西南農村信息化服務湖南省重點實驗室,湖南 邵陽 422000;3.湖南省農村農業信息化工程技術研究中心,湖南 長沙 410128)
基于Netty框架的農村應急廣播高并發數據處理
黃天天1,劉 波1, 2, 3
(1.湖南農業大學信息科學技術學院,湖南 長沙 410128;2.邵陽學院湘西南農村信息化服務湖南省重點實驗室,湖南 邵陽 422000;3.湖南省農村農業信息化工程技術研究中心,湖南 長沙 410128)
針對農村應急廣播系統集中高并發數據交互容易造成終端訪問服務器不穩定或死機的情況,分析了線程池和Netty框架的異步非阻塞高并發數據處理的優勢,提出了采用Netty框架和Java線程池分別處理網絡IO操作和業務邏輯、利用長連接提高通訊效率的解決方案。經測試,當并發請求數大于1 000時,該方案的響應時間比基于NIO的方案縮短了70%,數據處理速度提升了15.8%,且降低了通信異常出現的概率。該方案在湖南省和安徽省實施后,解決了廣播系統終端交互高訪問量下廣播不穩定的問題,系統運行良好,具有較高的穩定性。
并發數據處理;Netty框架;線程池;網絡通信;農村應急廣播系統
廣播電視是目前農村獲取信息以及休閑娛樂的主要工具,農村廣播系統作為各地方的重要民生工程,是農村公共文化服務體系建設的重要部分[1],可以傳達黨和政府的方針政策、科技商業信息,同時在防災救災和面臨突發事件時協助救災救援,發揮特殊作用。
近年來,移動互聯網與物聯網設備得到了迅猛發展,越來越明顯地改變著人類的生活方式。隨著現代化的廣播系統進一步深入農村,湖南省開始重點建立“村村響”農村應急廣播系統。張曉玲[2]根據湖南的地形特點,將3G技術引入廣播系統技術中,開發了3G廣播硬件終端,利用現有移動通訊網的寬廣覆蓋率提高山區廣播質量;在此基礎上,龔夢星等[3]進一步研究了ARM9嵌入式系統的廣播終端,并提出以節目播出單的形式控制終端播放節目和轉播調頻的新模式,開發了一套可以實現省、市、縣日常和應急廣播的web管理系統。湯喜春[4]總結和提出了山洪災害預警廣播和農村廣播“村村響”2個項目在技術和管理整合中存在的問題及相應的整合措施。筆者就湖南省長沙縣農村智能應急廣播系統研發和實現過程中出現的數據交互高并發造成的廣播不穩定問題提出了一種Netty框架和處理線程池相結合的解決方案。
高并發(High Concurrency)指的是在同一個時間點,有大量用戶同時訪問URL地址。高并發現象若處理不當將導致服務器被占滿崩潰、數據存儲和更新結果出現異常、用戶數據丟失和系統崩潰等現象。因此,高并發數據處理問題如不及時解決將給系統帶來嚴峻的考驗[5]。
針對當前湖南省農村農業信息化建設及農村文化宣傳陣地建設的需要,滿足農業信息化建設“村村響”的要求,設計和開發了農村應急廣播系統,目前已在湖南省長沙縣實施運行,部署了廣播子終端將近2 200個,并持續增加中。該系統中廣播終端通過訪問服務器端交互服務進行網絡通信,下載當日節目播出單和文件,并回傳終端的狀態信息等,實現智能定時廣播節目和轉播調頻,檢測終端運行情況,具體交互流程如圖1所示。

圖1 終端交互流程
為保證正常的日常廣播,所有廣播控制終端將在指定的交互時間(一般為凌晨),集體產生高頻率的訪問服務器行為來獲取當日需要播出的節目信息。由于網絡某些路由MSS(網絡傳輸數據最大值)限制為536字節,終端3G模塊的設定傳輸文件一次最大傳輸512字節,因此下載5 M大小的節目文件需要連續請求約10 240次,正常傳輸時下載單個文件需要40 min;同時,同一鄉鎮的終端交互時間一致,導致終端和服務器進行通信的時間基本相同,以致在終端交互的高峰時間段會產生非常驚人的數據交換量。
如圖2所示,2017年6月8日應急廣播系統服務器終端交互日志文件中統計的交互數據顯示,當天總交互12 799 799次,主要集中在0:00~3:00這個時間段,該時間段的平均訪問量為51 505次/min,最高82 397次/min,1秒內訪問量高達1 456次。由此可見,短短1 d就有高達千萬級別的交互量,且每秒并發量最高近1 500次。該系統對服務器網絡通信服務的性能要求非常高,而基于NIO實現的系統交互服務程序已經不能滿足需求,出現終端訪問中斷,獲取不到數據等問題,導致農村日常廣播不穩定。因此,解決高并發數據通信下不穩定的問題,提高服務器性能迫在眉睫。
通常來說,在不改變硬件條件的前提下,解決服務器高并發產生的問題主要是提升單機架構系統的并發能力。例如使用異步來增加單服務吞吐量,或者使用更高效率的數據結構來縮短響應時間等。楊小嬌[6]對Web服務器進行負載均衡優化,并優化HTTP長連接方案實現高并發實時傳輸;劉蓬[7]引入Proactor異步IO模型和基于排隊論的線程池動態調度模型對NIO 高性能框架作出了優化,提升了Java在網絡通信上面的處理效率。
對于當前系統使用的基于NIO框架的網絡傳輸,在處理數據時大量線程切換和生命周期處理消耗了系統資源,而NIO框架實現的是同步IO,未能實現異步處理;同系統使用短連接進行通信,在每次訪問時創建連接,通訊完畢后斷開,大大降低了系統性能。因此,結合應急廣播終端與系統交互的需求,主要可以利用線程池處理業務和IO操作,實現事件異步處理或利用長連接改進網絡傳輸來提高服務器性能。
Java NIO技術是一種新的、面向塊的、非阻塞的IO處理方式,采用select方式的多路復用機制實現[8],但按照POSIX標準來劃分NIO框架實現的是同步IO,而事件驅動模型利用事件觸發的方式實現了廣泛意義上的異步IO。當IO 操作準備就緒時,讀寫操作被觸發,此時使用IO線程池對數據進行處理,在網絡應用中可以在業務處理完成后觸發IO操作,避免因為每一個客戶端分配一個線程來處理連接的所有事件造成的阻塞,提高并發性能。
Netty通過異步事件驅動模型來觸發網絡IO的各種操作[9],模型的結構圖如圖3所示,該模型主要涉及到下面幾個核心的概念。
(1)Channel:表示一個與socket關聯的通道。
(2)ChannelPipeline:管道,一個Channel擁有一個ChannelPipeline,ChannelPipeline維護著一個處理鏈(嚴格的說是兩個:upstream傳入、downstream傳出),處理鏈是由很多處理句柄(ChannelHandler)所構成,每個句柄處理完以后會傳遞給鏈中的下一個處理句柄繼續處理。

圖2 2017年6月8日各時段服務器的交互量
(3)ChannelHandler:表示處理句柄,可以自定義處理句柄來進行發出請求前的預處理或處理每個請求,典型的有編碼器(decoder)、解碼器(encoder)。
(4)ChannelEvent:表示事件,是整個模型的處理對象,當產生或觸發(fire)一個事件時,該事件會沿著ChannelPipeline處理鏈依次被處理。
(5)ChannelFuture:表示異步結果,是異步事件處理的關鍵,當事件被處理時,可以不用在當前操作中被阻塞,直接以ChannelFuture的形式返回處理執行結果。得到結果的具體做法是在ChannelFuture添加監聽器listener,當操作被執行完成后listener會觸發,可以在listener的回調函數中預定義業務代碼。

圖3 異步事件驅動模型結構圖[9]
線程池的基本思想是一種對象池的思想,在內存中開辟一塊空間,存放一定數量活動的線程,線程池對象負責管理和調度這些活動的線程[10],可以減少創建、銷毀線程的次數及每個任務調用的開銷,在執行大量異步任務時能提高服務器性能。
Netty是個異步高性能的NIO框架,不提供業務容器和業務線程。若業務處理需要訪問數據庫或文件,直接使用Netty的IO線程處理業務可能會因執行時間不確定而導致線程被意外阻塞。因此,筆者采用Netty框架基于事件驅動的異步IO模型和業務處理線程池相結合的方式來處理高并發的網絡通信,即Netty只負責提供和管理NIO線程,而其他的主要業務層則采用Java的Thread Pool Executor定義線程池進行處理,提高系統性能。
JDK從1.5開始提供了ThreadPoolExecutor類來管理和自定義線程池[11]。newCachedThreadPool是創建一個可緩存線程池,如果線程池長度超過處理需要,可靈活回收空閑線程;若無可回收,則新建線程。此線程池不會對大小作限制,會根據處理需要動態調整,最大線程池尺寸一般不超過系統的資源限制,算法公式[12]如下:

其中,Nt為需要設置的核心線程數目,Nc為當前 CPU 的可用核心數,Nu為預期的 CPU 核心的利用率,T/C為任務的等待時間與計算時間的比值。
應急廣播系統中終端與服務器交互的數據處理主要包括接收數據的解析、訪問數據庫、讀取文件、數據發送的預處理等操作,其中解析和發送預處理由于執行時間短可定義解碼、編碼器交由Netty的IO線程處理,而其他則交由定義的處理線程池來完成,具體執行流程如圖4所示。其中,服務器監聽線程和IO操作線程池是Netty框架中的異步非阻塞線程,Java處理線程池是自定義的業務處理線程池。
長連接是指客戶端與服務器長時間保持連接,需要定時發送心跳報文以維持連接;若斷開需要重新建立連接。與短連接相比,若客戶端每次訪問服務器時要進行多次持續的數據交互,使用長連接可以節省多次打開和關閉連接的時間,提高網絡通信效率。心跳機制是保持長連接的關鍵,即客戶端或服務端每隔一段時間發送心跳包激活鏈路,同時也能檢測鏈路可用性,幫助客戶端或服務端及時斷開失效鏈路,釋放寶貴的IO資源[13]。
由于應急廣播系統中的流媒體直播功能需要保持終端服務器的長連接有效性,終端會定時向服務器端發送Ping消息,服務器收到后立即返回Pong消息,此為一次心跳檢測,若多次沒有收到回復,則認為該鏈路已經邏輯失效,將其關閉。服務器端可以利用Netty心跳檢測中基于鏈路空閑的讀空閑來實現心跳機制,即鏈路如果在持續時間t內沒有讀取到任何消息,那么在連續N次讀空閑超時發生時關閉連接鏈路,節省IO資源,提高系統通信效率和并發性能。

圖4 Netty IO線程池和動態線程池結合數據交互流程
該研究采用開源服務器壓力測試工具Jmeter分別對系統終端交互服務以基于Java NIO類庫和筆者方案的實現方式進行壓力測試,從系統響應時間和服務器IO吞吐量2個方面進行比較分析,由圖5可知,基于NIO的方案由于線程的切換對系統資源消耗較大,在并發請求數增大時導致系統響應時間過長,請求并發量2 000個時平均響應時間達0.7 s以上,而該研究提出的解決方案在并發量達到2 000個時響應時間依舊在0.02 s以下,尚未到達瓶頸;且當并發數目超過1 000時,對比NIO的方式平均響應時間縮短了70%以上。
在IO吞吐量方面,通過每次請求向服務器發送10 kB的數據進行測試。采用NIO的實現方案,隨著并發請求數目的增大,客戶端和服務器之間通信逐漸出現連接異常,造成吞吐量低,當并發量為2 000個時異常交互已達42%;而通過筆者提出的方案進行數據通信時,服務器端1秒可以處理18.5 kB的數據,并且無異常連接。如圖6所示,當并發量分別為1 000和2 000個時平均吞吐量增加了15.8%和134%。實驗證明,當6 000個客戶端同時連接服務器端時,系統仍然可以穩定可靠地運行。這說明筆者提出的Netty框架和業務處理線程池結合,使用長連接進行網絡通信的方案可以滿足應急廣播系統終端服務器交互穩定高并發的需求。

圖5 不同方式下并發請求平均響應時間的比較

圖6 不同方式下并發請求平均吞吐量的比較
目前,以該方案實現的終端交互服務,連同應急廣播系統已在湖南省長沙縣和安徽省合肥市部署,并與近2 200臺終端一起投入使用,在高交互量和高并發量的情況下能正常完成農村的日常廣播和緊急情況應急廣播的任務,未出現由于終端交互不穩定的原因造成的終端不按時廣播或死機的情況,運行效果良好。
根據農村智能應急廣播系統終端與服務器數據交互的高并發數據處理難題,提出了基于Netty框架和業務處理線程池結合的設計方案,實現了支持高并發量、復雜邏輯處理的網絡通信服務。經測試,當并發請求數大于1 000時,該方案的響應時間比基于NIO的方案縮短了70%,提升了15.8%的數據處理速度,降低了通信異常出現的概率,提高了系統的穩定性。該方案在湖南省和安徽省實施后,解決了智能應急廣播系統終端交互高訪問量下廣播不穩定的問題,系統運行良好,具有較高的穩定性。
[1] 張孝兵. GPRS無線通信在農村應急廣播系統中的應用[J]. 機電工程技術,2016,(Z2):383-387.
[2] 張曉玲. 基于3G網絡的農村廣播系統設計與實現[D]. 長沙:湖南農業大學,2014.
[3] 龔夢星,劉 波,黃天天,等. 基于SSM框架與嵌入式系統的農村應急廣播系統設計[J]. 軟件,2017,(5):43-48.
[4] 湯喜春. 湖南省山洪預警廣播綜合利用情況調研[J]. 中國防汛抗旱,2015,(5):64-66.
[5] 景安網絡. 究竟啥才是互聯網架構“高并發”[EB/OL]. http://server.zzidc.com/fwqjs/1522.html,2017-01-13.
[6] 楊小嬌. 輕量級高并發Web服務器的研究與實現[D]. 南京:南京郵電大學,2014.
[7] 劉 蓬. NIO高性能框架的研究與應用[D]. 長沙:湖南大學,2013.
[8] 吳高陽. 基于NIO的Java高性能網絡技術的研究與應用[D]. 西安:西安電子科技大學,2014.
[9] 殘 劍. Netty框架之異步事件驅動模型[EB/OL]. http://blog.chinaunix.net/uid-25885064-id-3425708.html,2012-11-29.
[10] 劉 文,王 標,王 丁. 基于Java線程池技術的數據爬蟲設計與實現[J]. 電腦編程技巧與維護,2016,(7):8-9.
[11] Pyarali I,Spivak M,Cytron R,et al. Evaluatingand optimizing thread pool strategies forreal-time CORBA[J]. ACM SIGPLAN Notices,2001,36(8):214-222.
[12] 吉 利,潘林云,劉 姚. 線程池技術在網絡服務器中的應用[J].計算機技術與發展,2017,(7):1-4.
[13] 代 超,鄧中亮. 基于Netty的面向移動終端的推送服務設計[J].軟件,2015,(12):1-4.
High Concurrency Data Processing of Rural Emergency Broadcasting Based on Netty Framework
HUANG Tian-tian1,LIU Bo1,2,3
(1. College of Information Science and Technology, Hunan Agricultural University, Changsha 410128, PRC; 2. Hunan Provincial Key Laboratory of Information Service in Rural of Southwestern Hunan, Shao yang Uniuersity, Shao yang 422000, PRC; 3. Hunan Engineering Technology Research Center of Agricultural & Rural Information, Changsha 410128, PRC)
Because of the centralized high concurrent data communication between the terminal and the server, the terminal access to the rural emergency broadcast system is easy to become unstable or crashed. After analyzing the advantages that the asynchronous and non blocking on high concurrency data processing of asynchronous pool and Netty framework, this paper proposes a solution that using the Netty framework to Handle network IO operation, java thread pool to process business logic, and long connection to improve communication efficiency. After testing, when the concurrent request number is more than 1000, the response time of the scheme reduced by 70% than scheme based on NIO. At the same time, it accelerates processing speed by 15.8% and reduces the probability of abnormal communications. The problem of broadcast instability in the broadcast system with high terminal access is solved after implementing the scheme in Hunan and Anhui Province, and the system runs well and stably.
concurrent data processing; Netty framework; thread pool; network communication; rural emergency broadcasting system
TP391
A
1006-060X(2017)09-0100-05
10.16498/j.cnki.hnnykx.2017.009.027
2017-07-22
湘西南農村信息化服務湖南省重點實驗室開放基金課題(XAI20150326);湖南省科技廳重點項目(2015NK2145,2016NK2118);2014湖南省教育廳科研一般項目(14C0542);2016年度湖南農業大學大學生創新性實驗計劃項目(XCX16094);湖南農業大學團委科技創新立項項目(自科類2016ZK15,2017ZK25)
黃天天(1993-),女,湖南株洲市人,碩士研究生,主要從事農業信息工程、農業物聯網研究。
劉 波
(責任編輯:成 平)