黃天天 ，劉 波 , 2, 3

（1.湖南農(nóng)業(yè)大學(xué)信息科學(xué)技術(shù)學(xué)院，湖南 長沙 410128；2.邵陽學(xué)院湘西南農(nóng)村信息化服務(wù)湖南省重點實驗室，湖南 邵陽 422000；3.湖南省農(nóng)村農(nóng)業(yè)信息化工程技術(shù)研究中心，湖南 長沙 410128）

基于Netty框架的農(nóng)村應(yīng)急廣播高并發(fā)數(shù)據(jù)處理

黃天天1，劉 波1, 2, 3

（1.湖南農(nóng)業(yè)大學(xué)信息科學(xué)技術(shù)學(xué)院，湖南 長沙 410128；2.邵陽學(xué)院湘西南農(nóng)村信息化服務(wù)湖南省重點實驗室，湖南 邵陽 422000；3.湖南省農(nóng)村農(nóng)業(yè)信息化工程技術(shù)研究中心，湖南 長沙 410128）

針對農(nóng)村應(yīng)急廣播系統(tǒng)集中高并發(fā)數(shù)據(jù)交互容易造成終端訪問服務(wù)器不穩(wěn)定或死機的情況，分析了線程池和Netty框架的異步非阻塞高并發(fā)數(shù)據(jù)處理的優(yōu)勢，提出了采用Netty框架和Java線程池分別處理網(wǎng)絡(luò)IO操作和業(yè)務(wù)邏輯、利用長連接提高通訊效率的解決方案。經(jīng)測試，當(dāng)并發(fā)請求數(shù)大于1 000時，該方案的響應(yīng)時間比基于NIO的方案縮短了70%，數(shù)據(jù)處理速度提升了15.8%，且降低了通信異常出現(xiàn)的概率。該方案在湖南省和安徽省實施后，解決了廣播系統(tǒng)終端交互高訪問量下廣播不穩(wěn)定的問題，系統(tǒng)運行良好，具有較高的穩(wěn)定性。

并發(fā)數(shù)據(jù)處理；Netty框架；線程池；網(wǎng)絡(luò)通信；農(nóng)村應(yīng)急廣播系統(tǒng)

廣播電視是目前農(nóng)村獲取信息以及休閑娛樂的主要工具，農(nóng)村廣播系統(tǒng)作為各地方的重要民生工程，是農(nóng)村公共文化服務(wù)體系建設(shè)的重要部分[1]，可以傳達黨和政府的方針政策、科技商業(yè)信息，同時在防災(zāi)救災(zāi)和面臨突發(fā)事件時協(xié)助救災(zāi)救援，發(fā)揮特殊作用。

近年來，移動互聯(lián)網(wǎng)與物聯(lián)網(wǎng)設(shè)備得到了迅猛發(fā)展，越來越明顯地改變著人類的生活方式。隨著現(xiàn)代化的廣播系統(tǒng)進一步深入農(nóng)村，湖南省開始重點建立“村村響”農(nóng)村應(yīng)急廣播系統(tǒng)。張曉玲[2]根據(jù)湖南的地形特點，將3G技術(shù)引入廣播系統(tǒng)技術(shù)中，開發(fā)了3G廣播硬件終端，利用現(xiàn)有移動通訊網(wǎng)的寬廣覆蓋率提高山區(qū)廣播質(zhì)量；在此基礎(chǔ)上，龔夢星等[3]進一步研究了ARM9嵌入式系統(tǒng)的廣播終端，并提出以節(jié)目播出單的形式控制終端播放節(jié)目和轉(zhuǎn)播調(diào)頻的新模式，開發(fā)了一套可以實現(xiàn)省、市、縣日常和應(yīng)急廣播的web管理系統(tǒng)。湯喜春[4]總結(jié)和提出了山洪災(zāi)害預(yù)警廣播和農(nóng)村廣播“村村響”2個項目在技術(shù)和管理整合中存在的問題及相應(yīng)的整合措施。筆者就湖南省長沙縣農(nóng)村智能應(yīng)急廣播系統(tǒng)研發(fā)和實現(xiàn)過程中出現(xiàn)的數(shù)據(jù)交互高并發(fā)造成的廣播不穩(wěn)定問題提出了一種Netty框架和處理線程池相結(jié)合的解決方案。

1 高并發(fā)數(shù)據(jù)通信

高并發(fā)（High Concurrency）指的是在同一個時間點，有大量用戶同時訪問URL地址。高并發(fā)現(xiàn)象若處理不當(dāng)將導(dǎo)致服務(wù)器被占滿崩潰、數(shù)據(jù)存儲和更新結(jié)果出現(xiàn)異常、用戶數(shù)據(jù)丟失和系統(tǒng)崩潰等現(xiàn)象。因此，高并發(fā)數(shù)據(jù)處理問題如不及時解決將給系統(tǒng)帶來嚴峻的考驗[5]。

1.1 應(yīng)急廣播系統(tǒng)高并發(fā)數(shù)據(jù)處理難題

針對當(dāng)前湖南省農(nóng)村農(nóng)業(yè)信息化建設(shè)及農(nóng)村文化宣傳陣地建設(shè)的需要，滿足農(nóng)業(yè)信息化建設(shè)“村村響”的要求，設(shè)計和開發(fā)了農(nóng)村應(yīng)急廣播系統(tǒng)，目前已在湖南省長沙縣實施運行，部署了廣播子終端將近2 200個，并持續(xù)增加中。該系統(tǒng)中廣播終端通過訪問服務(wù)器端交互服務(wù)進行網(wǎng)絡(luò)通信，下載當(dāng)日節(jié)目播出單和文件，并回傳終端的狀態(tài)信息等，實現(xiàn)智能定時廣播節(jié)目和轉(zhuǎn)播調(diào)頻，檢測終端運行情況，具體交互流程如圖1所示。

圖1 終端交互流程

為保證正常的日常廣播，所有廣播控制終端將在指定的交互時間（一般為凌晨），集體產(chǎn)生高頻率的訪問服務(wù)器行為來獲取當(dāng)日需要播出的節(jié)目信息。由于網(wǎng)絡(luò)某些路由MSS（網(wǎng)絡(luò)傳輸數(shù)據(jù)最大值）限制為536字節(jié)，終端3G模塊的設(shè)定傳輸文件一次最大傳輸512字節(jié)，因此下載5 M大小的節(jié)目文件需要連續(xù)請求約10 240次，正常傳輸時下載單個文件需要40 min；同時，同一鄉(xiāng)鎮(zhèn)的終端交互時間一致，導(dǎo)致終端和服務(wù)器進行通信的時間基本相同，以致在終端交互的高峰時間段會產(chǎn)生非常驚人的數(shù)據(jù)交換量。

如圖2所示，2017年6月8日應(yīng)急廣播系統(tǒng)服務(wù)器終端交互日志文件中統(tǒng)計的交互數(shù)據(jù)顯示，當(dāng)天總交互12 799 799次，主要集中在0:00～3:00這個時間段，該時間段的平均訪問量為51 505次/min，最高82 397次/min，1秒內(nèi)訪問量高達1 456次。由此可見，短短1 d就有高達千萬級別的交互量，且每秒并發(fā)量最高近1 500次。該系統(tǒng)對服務(wù)器網(wǎng)絡(luò)通信服務(wù)的性能要求非常高，而基于NIO實現(xiàn)的系統(tǒng)交互服務(wù)程序已經(jīng)不能滿足需求，出現(xiàn)終端訪問中斷，獲取不到數(shù)據(jù)等問題，導(dǎo)致農(nóng)村日常廣播不穩(wěn)定。因此，解決高并發(fā)數(shù)據(jù)通信下不穩(wěn)定的問題，提高服務(wù)器性能迫在眉睫。

1.2 高并發(fā)數(shù)據(jù)處理研究現(xiàn)狀

通常來說，在不改變硬件條件的前提下，解決服務(wù)器高并發(fā)產(chǎn)生的問題主要是提升單機架構(gòu)系統(tǒng)的并發(fā)能力。例如使用異步來增加單服務(wù)吞吐量，或者使用更高效率的數(shù)據(jù)結(jié)構(gòu)來縮短響應(yīng)時間等。楊小嬌[6]對Web服務(wù)器進行負載均衡優(yōu)化，并優(yōu)化HTTP長連接方案實現(xiàn)高并發(fā)實時傳輸；劉蓬[7]引入Proactor異步IO模型和基于排隊論的線程池動態(tài)調(diào)度模型對NIO 高性能框架作出了優(yōu)化，提升了Java在網(wǎng)絡(luò)通信上面的處理效率。

對于當(dāng)前系統(tǒng)使用的基于NIO框架的網(wǎng)絡(luò)傳輸，在處理數(shù)據(jù)時大量線程切換和生命周期處理消耗了系統(tǒng)資源，而NIO框架實現(xiàn)的是同步IO，未能實現(xiàn)異步處理；同系統(tǒng)使用短連接進行通信，在每次訪問時創(chuàng)建連接，通訊完畢后斷開，大大降低了系統(tǒng)性能。因此，結(jié)合應(yīng)急廣播終端與系統(tǒng)交互的需求，主要可以利用線程池處理業(yè)務(wù)和IO操作，實現(xiàn)事件異步處理或利用長連接改進網(wǎng)絡(luò)傳輸來提高服務(wù)器性能。

2 高并發(fā)數(shù)據(jù)處理方案

2.1 異步事件驅(qū)動模型

Java NIO技術(shù)是一種新的、面向塊的、非阻塞的IO處理方式，采用select方式的多路復(fù)用機制實現(xiàn)[8]，但按照POSIX標準來劃分NIO框架實現(xiàn)的是同步IO，而事件驅(qū)動模型利用事件觸發(fā)的方式實現(xiàn)了廣泛意義上的異步IO。當(dāng)IO 操作準備就緒時，讀寫操作被觸發(fā)，此時使用IO線程池對數(shù)據(jù)進行處理，在網(wǎng)絡(luò)應(yīng)用中可以在業(yè)務(wù)處理完成后觸發(fā)IO操作，避免因為每一個客戶端分配一個線程來處理連接的所有事件造成的阻塞，提高并發(fā)性能。

Netty通過異步事件驅(qū)動模型來觸發(fā)網(wǎng)絡(luò)IO的各種操作[9]，模型的結(jié)構(gòu)圖如圖3所示，該模型主要涉及到下面幾個核心的概念。

（1）Channel：表示一個與socket關(guān)聯(lián)的通道。

（2）ChannelPipeline：管道，一個Channel擁有一個ChannelPipeline，ChannelPipeline維護著一個處理鏈（嚴格的說是兩個：upstream傳入、downstream傳出），處理鏈是由很多處理句柄（ChannelHandler）所構(gòu)成，每個句柄處理完以后會傳遞給鏈中的下一個處理句柄繼續(xù)處理。

圖2 2017年6月8日各時段服務(wù)器的交互量

（3）ChannelHandler：表示處理句柄，可以自定義處理句柄來進行發(fā)出請求前的預(yù)處理或處理每個請求，典型的有編碼器（decoder）、解碼器（encoder）。

（4）ChannelEvent：表示事件，是整個模型的處理對象，當(dāng)產(chǎn)生或觸發(fā)（fire）一個事件時，該事件會沿著ChannelPipeline處理鏈依次被處理。

（5）ChannelFuture：表示異步結(jié)果，是異步事件處理的關(guān)鍵，當(dāng)事件被處理時，可以不用在當(dāng)前操作中被阻塞，直接以ChannelFuture的形式返回處理執(zhí)行結(jié)果。得到結(jié)果的具體做法是在ChannelFuture添加監(jiān)聽器listener，當(dāng)操作被執(zhí)行完成后listener會觸發(fā)，可以在listener的回調(diào)函數(shù)中預(yù)定義業(yè)務(wù)代碼。

圖3 異步事件驅(qū)動模型結(jié)構(gòu)圖[9]

2.2 業(yè)務(wù)處理線程池

線程池的基本思想是一種對象池的思想，在內(nèi)存中開辟一塊空間，存放一定數(shù)量活動的線程，線程池對象負責(zé)管理和調(diào)度這些活動的線程[10]，可以減少創(chuàng)建、銷毀線程的次數(shù)及每個任務(wù)調(diào)用的開銷，在執(zhí)行大量異步任務(wù)時能提高服務(wù)器性能。

Netty是個異步高性能的NIO框架，不提供業(yè)務(wù)容器和業(yè)務(wù)線程。若業(yè)務(wù)處理需要訪問數(shù)據(jù)庫或文件，直接使用Netty的IO線程處理業(yè)務(wù)可能會因執(zhí)行時間不確定而導(dǎo)致線程被意外阻塞。因此，筆者采用Netty框架基于事件驅(qū)動的異步IO模型和業(yè)務(wù)處理線程池相結(jié)合的方式來處理高并發(fā)的網(wǎng)絡(luò)通信，即Netty只負責(zé)提供和管理NIO線程，而其他的主要業(yè)務(wù)層則采用Java的Thread Pool Executor定義線程池進行處理，提高系統(tǒng)性能。

JDK從1.5開始提供了ThreadPoolExecutor類來管理和自定義線程池[11]。newCachedThreadPool是創(chuàng)建一個可緩存線程池，如果線程池長度超過處理需要，可靈活回收空閑線程；若無可回收，則新建線程。此線程池不會對大小作限制，會根據(jù)處理需要動態(tài)調(diào)整，最大線程池尺寸一般不超過系統(tǒng)的資源限制，算法公式[12]如下：

其中，Nt為需要設(shè)置的核心線程數(shù)目，Nc為當(dāng)前 CPU 的可用核心數(shù)，Nu為預(yù)期的 CPU 核心的利用率，T/C為任務(wù)的等待時間與計算時間的比值。

應(yīng)急廣播系統(tǒng)中終端與服務(wù)器交互的數(shù)據(jù)處理主要包括接收數(shù)據(jù)的解析、訪問數(shù)據(jù)庫、讀取文件、數(shù)據(jù)發(fā)送的預(yù)處理等操作，其中解析和發(fā)送預(yù)處理由于執(zhí)行時間短可定義解碼、編碼器交由Netty的IO線程處理，而其他則交由定義的處理線程池來完成，具體執(zhí)行流程如圖4所示。其中，服務(wù)器監(jiān)聽線程和IO操作線程池是Netty框架中的異步非阻塞線程，Java處理線程池是自定義的業(yè)務(wù)處理線程池。

2.3 數(shù)據(jù)處理長連接

長連接是指客戶端與服務(wù)器長時間保持連接，需要定時發(fā)送心跳報文以維持連接；若斷開需要重新建立連接。與短連接相比，若客戶端每次訪問服務(wù)器時要進行多次持續(xù)的數(shù)據(jù)交互，使用長連接可以節(jié)省多次打開和關(guān)閉連接的時間，提高網(wǎng)絡(luò)通信效率。心跳機制是保持長連接的關(guān)鍵，即客戶端或服務(wù)端每隔一段時間發(fā)送心跳包激活鏈路，同時也能檢測鏈路可用性，幫助客戶端或服務(wù)端及時斷開失效鏈路，釋放寶貴的IO資源[13]。

由于應(yīng)急廣播系統(tǒng)中的流媒體直播功能需要保持終端服務(wù)器的長連接有效性，終端會定時向服務(wù)器端發(fā)送Ping消息，服務(wù)器收到后立即返回Pong消息，此為一次心跳檢測，若多次沒有收到回復(fù)，則認為該鏈路已經(jīng)邏輯失效，將其關(guān)閉。服務(wù)器端可以利用Netty心跳檢測中基于鏈路空閑的讀空閑來實現(xiàn)心跳機制，即鏈路如果在持續(xù)時間t內(nèi)沒有讀取到任何消息，那么在連續(xù)N次讀空閑超時發(fā)生時關(guān)閉連接鏈路，節(jié)省IO資源，提高系統(tǒng)通信效率和并發(fā)性能。

圖4 Netty IO線程池和動態(tài)線程池結(jié)合數(shù)據(jù)交互流程

3 方案測試與應(yīng)用

該研究采用開源服務(wù)器壓力測試工具Jmeter分別對系統(tǒng)終端交互服務(wù)以基于Java NIO類庫和筆者方案的實現(xiàn)方式進行壓力測試，從系統(tǒng)響應(yīng)時間和服務(wù)器IO吞吐量2個方面進行比較分析，由圖5可知，基于NIO的方案由于線程的切換對系統(tǒng)資源消耗較大，在并發(fā)請求數(shù)增大時導(dǎo)致系統(tǒng)響應(yīng)時間過長，請求并發(fā)量2 000個時平均響應(yīng)時間達0.7 s以上，而該研究提出的解決方案在并發(fā)量達到2 000個時響應(yīng)時間依舊在0.02 s以下，尚未到達瓶頸；且當(dāng)并發(fā)數(shù)目超過1 000時，對比NIO的方式平均響應(yīng)時間縮短了70%以上。

在IO吞吐量方面，通過每次請求向服務(wù)器發(fā)送10 kB的數(shù)據(jù)進行測試。采用NIO的實現(xiàn)方案，隨著并發(fā)請求數(shù)目的增大，客戶端和服務(wù)器之間通信逐漸出現(xiàn)連接異常，造成吞吐量低，當(dāng)并發(fā)量為2 000個時異常交互已達42%；而通過筆者提出的方案進行數(shù)據(jù)通信時，服務(wù)器端1秒可以處理18.5 kB的數(shù)據(jù)，并且無異常連接。如圖6所示，當(dāng)并發(fā)量分別為1 000和2 000個時平均吞吐量增加了15.8%和134%。實驗證明，當(dāng)6 000個客戶端同時連接服務(wù)器端時，系統(tǒng)仍然可以穩(wěn)定可靠地運行。這說明筆者提出的Netty框架和業(yè)務(wù)處理線程池結(jié)合，使用長連接進行網(wǎng)絡(luò)通信的方案可以滿足應(yīng)急廣播系統(tǒng)終端服務(wù)器交互穩(wěn)定高并發(fā)的需求。

圖5 不同方式下并發(fā)請求平均響應(yīng)時間的比較

圖6 不同方式下并發(fā)請求平均吞吐量的比較

目前，以該方案實現(xiàn)的終端交互服務(wù)，連同應(yīng)急廣播系統(tǒng)已在湖南省長沙縣和安徽省合肥市部署，并與近2 200臺終端一起投入使用，在高交互量和高并發(fā)量的情況下能正常完成農(nóng)村的日常廣播和緊急情況應(yīng)急廣播的任務(wù)，未出現(xiàn)由于終端交互不穩(wěn)定的原因造成的終端不按時廣播或死機的情況，運行效果良好。

4 結(jié) 論

根據(jù)農(nóng)村智能應(yīng)急廣播系統(tǒng)終端與服務(wù)器數(shù)據(jù)交互的高并發(fā)數(shù)據(jù)處理難題，提出了基于Netty框架和業(yè)務(wù)處理線程池結(jié)合的設(shè)計方案，實現(xiàn)了支持高并發(fā)量、復(fù)雜邏輯處理的網(wǎng)絡(luò)通信服務(wù)。經(jīng)測試，當(dāng)并發(fā)請求數(shù)大于1 000時，該方案的響應(yīng)時間比基于NIO的方案縮短了70%，提升了15.8%的數(shù)據(jù)處理速度，降低了通信異常出現(xiàn)的概率，提高了系統(tǒng)的穩(wěn)定性。該方案在湖南省和安徽省實施后，解決了智能應(yīng)急廣播系統(tǒng)終端交互高訪問量下廣播不穩(wěn)定的問題，系統(tǒng)運行良好，具有較高的穩(wěn)定性。

[1] 張孝兵. GPRS無線通信在農(nóng)村應(yīng)急廣播系統(tǒng)中的應(yīng)用[J]. 機電工程技術(shù)，2016，（Z2）：383-387.

[2] 張曉玲. 基于3G網(wǎng)絡(luò)的農(nóng)村廣播系統(tǒng)設(shè)計與實現(xiàn)[D]. 長沙：湖南農(nóng)業(yè)大學(xué)，2014.

[3] 龔夢星，劉 波，黃天天，等. 基于SSM框架與嵌入式系統(tǒng)的農(nóng)村應(yīng)急廣播系統(tǒng)設(shè)計[J]. 軟件，2017，（5）：43-48.

[4] 湯喜春. 湖南省山洪預(yù)警廣播綜合利用情況調(diào)研[J]. 中國防汛抗旱，2015，（5）：64-66.

[5] 景安網(wǎng)絡(luò). 究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高并發(fā)”[EB/OL]. http：//server.zzidc.com/fwqjs/1522.html，2017-01-13.

[6] 楊小嬌. 輕量級高并發(fā)Web服務(wù)器的研究與實現(xiàn)[D]. 南京：南京郵電大學(xué)，2014.

[7] 劉 蓬. NIO高性能框架的研究與應(yīng)用[D]. 長沙：湖南大學(xué)，2013.

[8] 吳高陽. 基于NIO的Java高性能網(wǎng)絡(luò)技術(shù)的研究與應(yīng)用[D]. 西安：西安電子科技大學(xué)，2014.

[9] 殘 劍. Netty框架之異步事件驅(qū)動模型[EB/OL]. http：//blog.chinaunix.net/uid-25885064-id-3425708.html，2012-11-29.

[10] 劉 文，王 標，王 丁. 基于Java線程池技術(shù)的數(shù)據(jù)爬蟲設(shè)計與實現(xiàn)[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] 吉 利，潘林云，劉 姚. 線程池技術(shù)在網(wǎng)絡(luò)服務(wù)器中的應(yīng)用[J].計算機技術(shù)與發(fā)展，2017，（7）：1-4.

[13] 代 超，鄧中亮. 基于Netty的面向移動終端的推送服務(wù)設(shè)計[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

湘西南農(nóng)村信息化服務(wù)湖南省重點實驗室開放基金課題（XAI20150326）；湖南省科技廳重點項目（2015NK2145，2016NK2118）；2014湖南省教育廳科研一般項目（14C0542）；2016年度湖南農(nóng)業(yè)大學(xué)大學(xué)生創(chuàng)新性實驗計劃項目（XCX16094）；湖南農(nóng)業(yè)大學(xué)團委科技創(chuàng)新立項項目（自科類2016ZK15，2017ZK25）

黃天天（1993-），女，湖南株洲市人，碩士研究生，主要從事農(nóng)業(yè)信息工程、農(nóng)業(yè)物聯(lián)網(wǎng)研究。

劉 波

（責(zé)任編輯：成 平）