基于Netty框架的农村应急广播高并发数据处理
摘 要：针对农村应急广播系统集中高并发数据交互容易造成终端访问服务器不稳定或死机的情况，分析了线程池和Netty框架的异步非阻塞高并发数据处理的优势，提出了采用Netty框架和Java线程池分别处理网络IO操作和业务逻辑、利用长连接提高通讯效率的解决方案。经测试，当并发请求数大于1 000时，该方案的响应时间比基于NIO的方案缩短了70%，数据处理速度提升了15.8%，且降低了通信异常出现的概率。该方案在湖南省和安徽省实施后，解决了广播系统终端交互高访问量下广播不稳定的问题，系统运行良好，具有较高的稳定性。
关键词：并发数据处理；Netty框架；线程池；网络通信；农村应急广播系统
中图分类号：TP391 文献标识码：A 文章编号：1006-060X（2017）09-0100-05
High Concurrency Data Processing of Rural Emergency Broadcasting Based on Netty Framework
HUANG Tian-tian 1，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）
Abstract：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.
Key words：concurrent data processing； Netty framework； thread pool； network communication； rural emergency broadcasting system
廣播电视是目前农村获取信息以及休闲娱乐的主要工具，农村广播系统作为各地方的重要民生工程，是农村公共文化服务体系建设的重要部分[1]，可以传达党和政府的方针政策、科技商业信息，同时在防灾救灾和面临突发事件时协助救灾救援，发挥特殊作用。
近年来，移动互联网与物联网设备得到了迅猛发展，越来越明显地改变着人类的生活方式。随着现代化的广播系统进一步深入农村，湖南省开始重点建立“村村响”农村应急广播系统。张晓玲[2]根据湖南的地形特点，将3G技术引入广播系统技术中，开发了3G广播硬件终端，利用现有移动通讯网的宽广覆盖率提高山区广播质量；在此基础上，龚梦星等[3]进一步研究了ARM9嵌入式系统的广播终端，并提出以节目播出单的形式控制终端播放节目和转播调频的新模式，开发了一套可以实现省、市、县日常和应急广播的web管理系统。汤喜春[4]总结和提出了山洪灾害预警广播和农村广播“村村响”2个项目在技术和管理整合中存在的问题及相应的整合措施。笔者就湖南省长沙县农村智能应急广播系统研发和实现过程中出现的数据交互高并发造成的广播不稳定问题提出了一种Netty框架和处理线程池相结合的解决方案。
1 高并发数据通信
高并发（High Concurrency）指的是在同一个时间点，有大量用户同时访问URL地址。高并发现象若处理不当将导致服务器被占满崩溃、数据存储和更新结果出现异常、用户数据丢失和系统崩溃等现象。因此，高并发数据处理问题如不及时解决将给系统带来严峻的考验[5]。
1.1 应急广播系统高并发数据处理难题
针对当前湖南省农村农业信息化建设及农村文化宣传阵地建设的需要，满足农业信息化建设“村村响”的要求，设计和开发了农村应急广播系统，目前已在湖南省长沙县实施运行，部署了广播子终端将近2 200个，并持续增加中。该系统中广播终端通过访问服务器端交互服务进行网络通信，下载当日节目播出单和文件，并回传终端的状态信息等，实现智能定时广播节目和转播调频，检测终端运行情况，具体交互流程如图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实现的系统交互服务程序已经不能满足需求，出现终端访问中断，获取不到数据等问题，导致农村日常广播不稳定。因此，解决高并发数据通信下不稳定的问题，提高服务器性能迫在眉睫。
1.2 高并发数据处理研究现状
通常来说，在不改变硬件条件的前提下，解决服务器高并发产生的问题主要是提升單机架构系统的并发能力。例如使用异步来增加单服务吞吐量，或者使用更高效率的数据结构来缩短响应时间等。杨小娇[6]对Web服务器进行负载均衡优化，并优化HTTP长连接方案实现高并发实时传输；刘蓬[7]引入Proactor异步IO模型和基于排队论的线程池动态调度模型对 NIO 高性能框架作出了优化，提升了Java在网络通信上面的处理效率。
对于当前系统使用的基于NIO框架的网络传输，在处理数据时大量线程切换和生命周期处理消耗了系统资源，而NIO框架实现的是同步IO，未能实现异步处理；同系统使用短连接进行通信，在每次访问时创建连接，通讯完毕后断开，大大降低了系统性能。因此，结合应急广播终端与系统交互的需求，主要可以利用线程池处理业务和IO操作，实现事件异步处理或利用长连接改进网络传输来提高服务器性能。
2 高并发数据处理方案
2.1 异步事件驱动模型
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）所构成，每个句柄处理完以后会传递给链中的下一个处理句柄继续处理。
（3）ChannelHandler：表示处理句柄，可以自定义处理句柄来进行发出请求前的预处理或处理每个请求，典型的有编码器（decoder）、解码器（encoder）。
（4）ChannelEvent：表示事件，是整个模型的处理对象，当产生或触发（fire）一个事件时，该事件会沿着ChannelPipeline处理链依次被处理。
（5）ChannelFuture：表示异步结果，是异步事件处理的关键，当事件被处理时，可以不用在当前操作中被阻塞，直接以ChannelFuture的形式返回处理执行结果。得到结果的具体做法是在ChannelFuture添加监听器listener，当操作被执行完成后listener会触发，可以在listener的回调函数中预定义业务代码。
2.2 业务处理线程池
线程池的基本思想是一种对象池的思想，在内存中开辟一块空间，存放一定数量活动的线程，线程池对象负责管理和调度这些活动的线程[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处理线程池是自定义的业务处理线程池。
2.3 数据处理长连接
长连接是指客户端与服务器长时间保持连接，需要定时发送心跳报文以维持连接；若断开需要重新建立连接。与短连接相比，若客户端每次访问服务器时要进行多次持续的数据交互，使用长连接可以节省多次打开和关闭连接的时间，提高网络通信效率。心跳机制是保持长连接的关键，即客户端或服务端每隔一段时间发送心跳包激活链路，同时也能检测链路可用性，帮助客户端或服务端及时断开失效链路，释放宝贵的IO资源[13]。
由于应急广播系统中的流媒体直播功能需要保持终端服务器的长连接有效性，终端会定时向服务器端发送Ping消息，服务器收到后立即返回Pong消息，此为一次心跳检测，若多次没有收到回复，则认为该链路已经逻辑失效，将其关闭。服务器端可以利用Netty心跳检测中基于链路空闲的读空闲来实现心跳机制，即链路如果在持续时间t内没有读取到任何消息，那么在连续N次读空闲超时发生时关闭连接链路，节省IO资源，提高系统通信效率和并发性能。
3 方案测试与应用
该研究采用开源服务器压力测试工具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框架和业务处理线程池结合，使用长连接进行网络通信的方案可以满足应急广播系统终端服务器交互稳定高并发的需求。
目前，以该方案实现的终端交互服务，连同应急广播系统已在湖南省长沙县和安徽省合肥市部署，并与近2 200台终端一起投入使用，在高交互量和高并发量的情况下能正常完成农村的日常广播和紧急情况应急广播的任务，未出现由于终端交互不稳定的原因造成的终端不按时广播或死机的情况，运行效果良好。
4 结 论
根据农村智能应急广播系统终端与服务器数据交互的高并发数据处理难题，提出了基于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.
（责任编辑：成 平）