APP下载

基于EPOLL 编程模型的全路车流径路服务的开发与应用

2020-10-28邓桂星李世春刘耀宗

铁路计算机应用 2020年10期
关键词:径路描述符车流

邓桂星,张 锐,李世春,刘耀宗,王 瑜

(中国铁路兰州局集团有限公司 信息技术所,兰州 730000)

车流径路是当前我国铁路优化运输组织、合理分配运力资源、提升路网整体通过能力的重要技术手段,为铁路货运编组计划制定、运到时限考核、车流推算、违规车流判定、计费径路调整等业务提供必要的数据支持。先前开发的“可视化铁路网货流、车流公共信息平台”[1]解决了全路车流径路判定的问题,广泛应用于货运、运输[2]、调度和统计等业务信息系统[3]。但这些应用采用本地计算模式,依赖于最新下载的车流径路数据,若未及时更新径路数据,会造成计算结果与运输实际情况的差异,不利于运输组织和经营考核。

为解决上述问题,在64 bit Linux 操作系统上,利用 Eclipse 开发工具和I/O 编程模型EPOLL,开发全路车流径路服务,实现全路车流径路数据的集中计算与分布应用。

WebLogic 与Tomcat 服务均基于Java 语言,而先前开发的车流径路算法程序基于C++语言,跨语言代码调用需借助JNA,会显著降低系统运行效率。且传统网络通讯SELECT 编程模型已不能满足目前访问车流径路数据的大量客户端连接和高速数据传输需求。EPOLL 编程模型是Linux 内核为处理大批量文件描述符而改进的POLL,是Linux 操作系统上多路复用I/O 接口-SELECT/POLL 的增强版本,在大量并发连接中只有部分连接活跃的情况下,可显著提高系统CPU 利用率[4]。经过与Windows 操作系统上的SELECT 编程模型和IOCP 编程模型的实验对比,发现在Linux 操作系统上采用EPOLL 编程模型开发应用服务,代码维护简洁、并发处理能力强、读写效率高,能够满足访问车流径路数据的大量客户端连接及高速数据传输的需求。

1 EPOLL 编程模型

EPOLL 编程模型与SELECT/POLL 类似,均是基于TCP/IP 网络传输协议的套接字编程模型,但EPOLL 模型可承载更多并发客户端连接,采用内存映射等技术,且系统调用时只处理活跃连接,执行效率更高[4],其工作流程如图1 所示。

图1 EPOLL 编程模型的工作流程

1.1 3个核心函数

(1)INT EPOLL_CREATE(INT SIZE),用于生成一个EPOLL 专用的文件描述符,即申请一段内存空间来存放被关注的套接字上发生的事件;参数SIZE 是系统连接的最大客户端数量,可被省略(此时取系统最大值)[5]。

(2)INT EPOLL_CTL(···,STRUCT EPOLL_EVENT *EV),用于控制被关注的文件描述符上发生的事件:注册、修改、删除;参数EV 用于通知操作系统需要监听何种事件。

(3)INT EPOLL_WAIT(···, STRUCT EPOLL_EVENT *EVENTS,···),用于获取有触发事件的文件描述符;函数调用过程中使用内存映射(MMAP)技术,免去复制文件描述符的开销[4]。

1.2 工作方式的选择

水平触发方式(LT,Level Triggered):操作系统会通知文件描述符是否就绪;若已就绪,程序可读写就绪的套接字;若程序未做任何操作,操作系统会继续发出通知;水平触发方式编程出错的可能性小,但处理速度慢[5]。

边沿触发方式(ET,Edge Triggered):是一种高速工作方式,只支持非阻塞,比水平触发效率高;当一个事件发生时,可调用EPOLL_WAIT 获取该事件,若系统尚未处理完该事件对应的套接字缓冲区,而这个套接字中没有新的事件发生时,不能再通过EPOLL_WAIT 调用获得该事件[5]。

水平触发方式下,开发EPOLL 服务简单且不易出错;边沿触发方式下,程序运算速度快,但代码略微复杂。

车流径路服务的开发采用边沿触发方式。

2 基于EPOLL 编程模型的车流径路服务的开发

基于EPOLL 编程模型的车流径路服务的开发包括车流径路系统[6]的移植与EPOLL 服务的设计与实现。

2.1 车流径路系统的移植

先前开发的车流径路系统是在Win32 操作系统上采用标准C++语言开发的。而车流径路系统的移植利用Linux 版Eclipse 作为开发工具[7],需解决从32 bit 操作系统移植到64 bit 操作系统的相关问题。在32 bit 操作系统上,long 和pointer 变量的长度为4 byte[8],在64 bit 操作系统上则为8 byte,移植后会造成内存空间大小的变化以及读取二进制文件错位等问题。为此,采用宏定义统一变量长度,编译生成.SO 文件(动态链接库),供EPOLL 模型调用。

64 bit 操作系统的寻址能力更强,可显著提高运行效率。经实验对比发现,在Win32 操作系统的单进程模式下,每秒钟能计算7万条车流径路数据,Linux64 操作系统下则可达10万条左右。

2.2 车流径路服务的设计与实现

基于EPOLL 模型的服务采用多线程技术来提高访问效率;主线程负责收集已经发生的客户端事件、径路计算和数据传输,监听线程负责处理新的客户端连接。

如图2 所示,车流径路服务的建立过程如下:

图2 车流径路服务的建立过程

(1)调用EPOLL_CREATE()生成一个EPOLL 专用的文件描述符,并启动车流径路系统;

(2)在主线程中调用EPOLL_WAIT()收集已经发生的客户端事件,并进行车流径路计算和数据传输;

(3)启动监听线程,专门处理新的客户端连接,管理客户端队列;

(4)卸载车流径路数据,清空客户端队列,关闭EPOLL 专用文件描述符,退出服务。

3 测试及应用效果

在实验环境下,采取多线程技术[9]模拟客户端的并发访问,进行压力测试。在创建10000个并发线程时,基于EPOLL 编程模型的车流径路服务的连接、运算和传输都较为稳定,CPU 利用率和内存占用率均在正常范围内。与Tomcat 服务、SELECT 和IOCP 编程模型相比,基于EPOLL 编程模型的车流径路服务在编程复杂度、传输效率和稳定性方面均有明显优势。目前,该服务已为全路车流径路的实时查询、货物运到时限预警、承运清算以及铁路局的其它特色应用提供支持,每日计算量在10万次以上,高峰访问并发量约1000个用户。经过一年的运行监测,该服务运行稳定,未发现异常状况。

4 结束语

Linux 操作系统及EPOLL 编程模型具有高并发、高效率和高稳定性,满足国产化应用的开发需求,使应用系统开发摆脱了对商业中间件的依赖。利用Linux 操作系统内核的高并发处理机制,较好地解决了车流径路共享难题,实现全路车流径路数据的集中运算和分布应用。

今后,还将采用二进制流方式进行数据传输,以提高数据的安全性和传输效率。

猜你喜欢

径路描述符车流
面向全路的货车车流径路公共技术服务平台研究与设计
插入性室性早搏揭示房室结双径路Lorenz-RR散点图1例
车流径路辅助决策系统优化与实践
基于车流径路选择偏好的铁路车流运行径路动态预测方法研究
基于改进点-弧模型的铁路网车流径路优化模型研究
基于AKAZE的BOLD掩码描述符的匹配算法的研究
欧洲共同语言参考标准在中国高校学术英语写作教学适用性的研究:可理解性,可行性和有用性
道路躁动
故乡的车流(外一首)
基于深度学习的局部描述符