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

黃天天 ，劉 波 , 2, 3

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

針對(duì)農(nóng)村應(yīng)急廣播系統(tǒng)集中高并發(fā)數(shù)據(jù)交互容易造成終端訪問服務(wù)器不穩(wěn)定或死機(jī)的情況，分析了線程池和Netty框架的異步非阻塞高并發(fā)數(shù)據(jù)處理的優(yōu)勢(shì)，提出了采用Netty框架和Java線程池分別處理網(wǎng)絡(luò)IO操作和業(yè)務(wù)邏輯、利用長連接提高通訊效率的解決方案。經(jīng)測(cè)試，當(dāng)并發(fā)請(qǐng)求數(shù)大于1 000時(shí)，該方案的響應(yīng)時(shí)間比基于NIO的方案縮短了70%，數(shù)據(jù)處理速度提升了15.8%，且降低了通信異常出現(xiàn)的概率。該方案在湖南省和安徽省實(shí)施后，解決了廣播系統(tǒng)終端交互高訪問量下廣播不穩(wěn)定的問題，系統(tǒng)運(yùn)行良好，具有較高的穩(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]，可以傳達(dá)黨和政府的方針政策、科技商業(yè)信息，同時(shí)在防災(zāi)救災(zāi)和面臨突發(fā)事件時(shí)協(xié)助救災(zāi)救援，發(fā)揮特殊作用。

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

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

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

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

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

圖1 終端交互流程

為保證正常的日常廣播，所有廣播控制終端將在指定的交互時(shí)間（一般為凌晨），集體產(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ù)請(qǐng)求約10 240次，正常傳輸時(shí)下載單個(gè)文件需要40 min；同時(shí)，同一鄉(xiāng)鎮(zhèn)的終端交互時(shí)間一致，導(dǎo)致終端和服務(wù)器進(jìn)行通信的時(shí)間基本相同，以致在終端交互的高峰時(shí)間段會(huì)產(chǎn)生非常驚人的數(shù)據(jù)交換量。

如圖2所示，2017年6月8日應(yīng)急廣播系統(tǒng)服務(wù)器終端交互日志文件中統(tǒng)計(jì)的交互數(shù)據(jù)顯示，當(dāng)天總交互12 799 799次，主要集中在0:00～3:00這個(gè)時(shí)間段，該時(shí)間段的平均訪問量為51 505次/min，最高82 397次/min，1秒內(nèi)訪問量高達(dá)1 456次。由此可見，短短1 d就有高達(dá)千萬級(jí)別的交互量，且每秒并發(fā)量最高近1 500次。該系統(tǒng)對(duì)服務(wù)器網(wǎng)絡(luò)通信服務(wù)的性能要求非常高，而基于NIO實(shí)現(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)生的問題主要是提升單機(jī)架構(gòu)系統(tǒng)的并發(fā)能力。例如使用異步來增加單服務(wù)吞吐量，或者使用更高效率的數(shù)據(jù)結(jié)構(gòu)來縮短響應(yīng)時(shí)間等。楊小嬌[6]對(duì)Web服務(wù)器進(jìn)行負(fù)載均衡優(yōu)化，并優(yōu)化HTTP長連接方案實(shí)現(xiàn)高并發(fā)實(shí)時(shí)傳輸；劉蓬[7]引入Proactor異步IO模型和基于排隊(duì)論的線程池動(dòng)態(tài)調(diào)度模型對(duì)NIO 高性能框架作出了優(yōu)化，提升了Java在網(wǎng)絡(luò)通信上面的處理效率。

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

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

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

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

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

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

（2）ChannelPipeline：管道，一個(gè)Channel擁有一個(gè)ChannelPipeline，ChannelPipeline維護(hù)著一個(gè)處理鏈（嚴(yán)格的說是兩個(gè)：upstream傳入、downstream傳出），處理鏈?zhǔn)怯珊芏嗵幚砭浔–hannelHandler）所構(gòu)成，每個(gè)句柄處理完以后會(huì)傳遞給鏈中的下一個(gè)處理句柄繼續(xù)處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié) 論

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

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

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

[3] 龔夢(mèng)星，劉 波，黃天天，等. 基于SSM框架與嵌入式系統(tǒng)的農(nóng)村應(yīng)急廣播系統(tǒng)設(shè)計(jì)[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] 楊小嬌. 輕量級(jí)高并發(fā)Web服務(wù)器的研究與實(shí)現(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ū)動(dòng)模型[EB/OL]. http：//blog.chinaunix.net/uid-25885064-id-3425708.html，2012-11-29.

[10] 劉 文，王 標(biāo)，王 丁. 基于Java線程池技術(shù)的數(shù)據(jù)爬蟲設(shè)計(jì)與實(shí)現(xiàn)[J]. 電腦編程技巧與維護(hù)，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].計(jì)算機(jī)技術(shù)與發(fā)展，2017，（7）：1-4.

[13] 代 超，鄧中亮. 基于Netty的面向移動(dòng)終端的推送服務(wù)設(shè)計(jì)[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ù)湖南省重點(diǎn)實(shí)驗(yàn)室開放基金課題（XAI20150326）；湖南省科技廳重點(diǎn)項(xiàng)目（2015NK2145，2016NK2118）；2014湖南省教育廳科研一般項(xiàng)目（14C0542）；2016年度湖南農(nóng)業(yè)大學(xué)大學(xué)生創(chuàng)新性實(shí)驗(yàn)計(jì)劃項(xiàng)目（XCX16094）；湖南農(nóng)業(yè)大學(xué)團(tuán)委科技創(chuàng)新立項(xiàng)項(xiàng)目（自科類2016ZK15，2017ZK25）

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

劉 波

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