面向物联网的复杂事件处理引擎状态监控与灾难恢复方法与流程

本发明涉及物联网传感器网络、物联网中间件、复杂事件处理等技术领域，具体涉及复杂事件处理引擎的状态监控及引擎灾难恢复方法。

背景技术：

物联网传感器网络是一种由独立分布的节点以及网关构成的传感器网络。传感器的类型多种多样，所以物联网能够促进各种应用在不同领域的发展，例如家居自动化、工业自动化、医疗援助、移动医疗保健、老年人辅助、智能能源管理、智能网格自动化交通管理等等其他方面。在物联网传感器网络中，安放在不同地点的传感器节点不断采集着外界的物理信息，如温度、声音、震动等。传感器网络的每个节点都能够实现采集，数据的简单处理，还能接收来自其他节点的数据，并最终将数据发送到网关。开发者或工程师可以从网关获取数据，查看历史数据记录或进行分析。

物联网中间件技术是在当前物联网环境下，解决设备异构、信息海量、数据类型多等问题的通用服务平台，实现对物的管理、交互和信息处理等功能。物联网中间件处于系统架构的中间部分，介于物联网底层硬件/操作系统和上层应用程序之间，其作用是减轻上层应用的数据处理负担，屏蔽物联网环境中的异构性，提高可移植性。当前物联网环境中，使用最广泛的传感器设备是rfid传感器，因此rfid中间件占据了主流，它的主要任务是对阅读器传来的与标签相关的事件、数据进行清洗、过滤和计算，减少从阅读器传往企业应用的巨量原始数据，提取出有意义的信息供企业使用。

复杂事件处理技术是一种把数据流作为输入，根据一系列预定义的规则，把数据（或部分数据）重定向给监听者们；又或者是当发现数据中的隐含的模式（pattern）时，触发事件。在大量数据产生出来并需要进行实时地分析的场景下，复杂事件处理技术可以有效地分析数据，找出其中包含的事件。目前复杂事件处理技术的研究有很多，它们主要集中在两个方面，分别是复杂事件处理语言和复杂事件检测。复杂事件处理语言有比较成熟的epl（eventprocessinglanguage）语言，使用一系列的子句，从事件流中查找复杂事件。复杂事件检测也有很多成熟的算法，比如基于有向图的、基于petri网的等等。

现有的复杂事件处理技术主要集中在对复杂事件处理引擎的研究上，其中主要对事件检测、事件匹配和事件处理性能的研究。当复杂事件处理引擎应用在物联网环境中时，人们不仅要关注复杂事件处理引擎本身的性能，还要使复杂事件处理引擎在复杂的物联网环境中能够保证实时可用性与可恢复性，满足实际业务的需求。于是本发明就针对这两点特性描述了一种能够对复杂事件处理引擎状态监控与灾难恢复的方法。

技术实现要素：

本发明的目的在于克服现有技术存在上述不足，提供了面向物联网的复杂事件处理引擎状态监控与灾难恢复方法，具体包括对复杂事件处理引擎的状态监听和控制方法，以及引擎发生故障后对故障期间的事件流进行暂存和重加载的方法。

面向物联网的复杂事件处理引擎状态监控与灾难恢复方法：对复杂事件处理引擎esper（下文所述复杂事件处理引擎皆指esper引擎）的状态进行监听和控制，并且在复杂事件处理引擎发生故障重启之后能够对故障期间丢失的原子事件，即传感器读取到的初始事件，进行再次处理，帮助复杂事件处理引擎从灾难中恢复；复杂事件处理引擎状态监控是指：服务器端的复杂事件处理引擎的运行状态能够被前端实时监听，前端在监听到复杂事件处理引擎状态后还能够根据实施情况对复杂事件处理引擎的状态进行控制，包括对复杂事件处理引擎的暂停，重新实例化操作；

复杂事件处理引擎灾难恢复是指：当复杂事件处理引擎发生故障后，故障期间输入的原子事件流将被保存到数据库中进行暂存，在对复杂事件处理引擎重新实例化后将故障期间暂存的原子事件流输入复杂事件处理引擎进行复杂事件处理；为使复杂事件处理引擎能够在故障中恢复，需建立一个多级的数据持久化模块，使用事件缓存区、临时数据库和永久数据库三层存储方式进行事件的数据暂存和数据长期持久化，进行多级别的事件存储。

进一步地，前端不断监听来自服务器端复杂事件处理引擎的状态消息，当复杂事件处理引擎的状态是正常运行时，前端不做任何处理，当复杂事件处理引擎的状态处于错误状态时，前端将会及时报告复杂事件处理引擎错误信息，并且能根据前端使用者的选择进行下一步操作，进行复杂事件处理引擎的重新启动或故障排除。

进一步地，对复杂事件处理引擎的监听控制模块运行在服务器端，监听控制模块包括监听器和控制器两个部分。监听控制模块的监听器对复杂事件处理引擎的状态进行监听，并且将复杂事件处理引擎状态信息报告给前端；监听控制模块的控制器对引擎进行控制，包括挂起、继续、重启、关闭。

进一步地，监听控制模块中控制器对复杂事件处理引擎的控制操作不仅是暂停、继续，还包括根据复杂事件处理引擎当前状态决定是重启动还是加载不同的数据源重新实例化。

进一步地，复杂事件处理引擎发生错误时监听控制模块中的控制器能够将还在源源不断输入的事件流输出到一个临时数据库暂时存储起来，在复杂事件处理引擎重启动之后，根据前端的指令决定是从临时数据库加载数据还是从传感器直接接收数据。

进一步地，复杂事件处理引擎从灾难中恢复并且重启之后，如果从临时数据库加载数据，那么传感器输入的事件流将会存到临时缓存区，临时缓存区创建于内存中提高读取速度。

进一步地，对于复杂事件处理引擎的状态监控与灾难恢复，需要在服务器端创建监听控制模块，该模块中的监听器listener对复杂事件处理引擎的运行状态进行监听，并且将引擎的状态信息返回给前端，前端实时更新引擎的状态信息供前端使用者查看。前端可以向服务器端的控制器发送消息，控制复杂事件处理引擎的状态。当监听器监听到复杂事件处理引擎发生故障，将启动灾难恢复的处理操作。

进一步地，当复杂事件处理引擎发生故障时，监听器得到这一消息会做两件事情，首先将来自传感器的原子事件流存到临时数据库中，同时返回引擎发生故障的信息发送给前端。在这种情况下，前端的使用者可以选择对复杂事件引擎进行故障排除或重新启动的操作。

进一步地，前端向服务器端的控制器发出控制指令，该指令中包含了控制的方式，包括挂起、继续、重启、关闭。控制器收到来自前端的指令，直接对复杂事件处理引擎进行相应的控制。

进一步地，如果控制器controller收到来自前端的重启指令后，根据指令内容对复杂事件处理引擎进行重启操作。如果控制器controller收到重新实例化的指令，将对复杂事件处理引擎进行重新实例化，旧的复杂事件处理引擎实例将被销毁。

进一步地，重启或者重新实例化之后的复杂事件处理引擎根据指令不同会加载不同的数据源，包括从临时数据库加载和从实时原子事件流加载两种方式。临时数据库中存储的故障期间的原子事件流会在重启动之后被传入引擎或者直接转存到事件永久数据库中，以供进行历史记录查询。

进一步地，如果引擎在重启后从临时数据库加载数据，此时从传感器传入的事件流保存到创建在内存中的缓存区eventbuffer，等待临时数据库中的事件被引擎读取完之后，再从缓存区读取事件，最后接收来自传感器的实时事件流。

进一步地，通过对复杂事件处理引擎的监听与控制，并且利用多级的数据持久化模块，实现物联网环境下的复杂事件处理引擎的状态监控与灾难恢复，提高复杂事件处理引擎的可靠性与可恢复性。

与现有技术相比，本发明具有如下优点和技术效果：

（1）在服务器端创建监听控制模块，保证对引擎的监听实时性

复杂事件处理引擎esper虽然提供了复杂事件查询的功能，但是对于引擎的控制还只能通过简单的实例化运行，如果引擎发生故障，将不能及时报告给使用者。因此，在服务器端创建监听控制模块，对引擎的状态进行实时监听，能够让使用者在前端及时知道引擎的运行状态，并且，服务器端的监听器与引擎运行在同一台主机上，保证了二者之间是绑定的关系，保证了对引擎监听的实时性。

（2）设计前端与服务器端监听控制模块的通信方式，保证对引擎的可控性

前端不直接控制复杂事件处理引擎，而是与部署在服务器端的监听控制模块进行通信，监听控制模块将引擎的状态信息不断报告给前端，前端对引擎的控制指令发送给监听控制模块，再通过监听控制模块实现对引擎的控制，包括挂起、继续、重启、关闭操作，这样保证使用者通过前端对引擎的可控性。

（3）设计多级备份存储的方式，保证事件流的可恢复性

通过建立缓存区eventbuffer、临时数据库tempdb、永久数据库permdb的方式，对事件流做不同级别的存储。当引擎工作运行时，事件流被引擎处理的同时直接存入永久数据库做数据持久化；当引擎发生故障时，事件流被存入临时数据库做备份，当引擎重新启动之后再从临时数据库导入引擎，这时如果来自物联网传感器的事件流传入引擎，但是临时数据库中的事件还未处理完，那么实时事件流将被存入缓存区进行暂存，等到临时数据库中的事件处理完成就读取缓存区的事件。通过这种多级的备份存储方式，保证了引擎在发生故障时不会遗漏重要的事件，保证了事件流的可恢复性。

（4）设计不同的引擎重启方式，保证事件的实时处理性或完整性

对于发生故障的复杂事件处理引擎，当故障被解决之后，引擎重启有两种方式可供选择，一种是丢弃故障期间的事件流直接重启引擎，第二种是加载临时数据库，读取故障期间的事件流，再读取实时事件流。通过这两种方式满足事件处理的实时处理性或者完整性。

附图说明

图1为系统功能架构图。

图2为系统部署结构图。

图3为原子事件组成示意图。

图4为复杂事件处理引擎实例化简要过程图。

图5为引擎的监控流程图。

图6为引擎的灾难恢复图。

具体实施方式

为了使本发明的技术方案及优点更加清楚明白，下面结合附图，进行进一步的详细说明，但本发明的实施和保护不限于此，需指出的是，以下文字或附图中若有未特别详细说明之处如字符均是本领域及人员可参照现有技术理解或实现的。

本实例采用如下复杂事件处理系统来作为面向物联网的复杂事件处理引擎状态监控与灾难恢复方法的实例。

整个系统的总体架构如图1所示，其中物联网中间件由设备适配层（deviceadapter）、设备管理层（devicemanager）、和ale服务层（aleservice）以及规则管理调度层（ruleadapter）组成，复杂事件处理系统由事件输入适配层（eventinputadapter）、规则输入适配层（ruleinputadapter）、规则/事件分组策略层（streamgroupingmanager）、复杂事件处理引擎（complexeventprocessor）以及复杂事件输出适配层（eventoutputadapter）组成，监听/控制模块由监听器（listener）和控制器（controller）组成，多级存储层由事件缓存区（eventbuffer）、临时数据库（tempdb）以及永久数据库（permdb）组成，前端监控由用户界面（userinterface）和远程访问模块（remoteaccessmodule）组成。物联网传感器采集的数据经由ale服务层进行预处理，然后以ecreport的形式传递给输入适配层，输入适配层将数据转换为原子事件并通过事件流分组策略层以pojo的形式输入复杂事件处理引擎。而规则管理调度层与规则输入适配层进行交互，再将预先制定好的规则调度元数据推送到规则/事件分组策略层，分组策略层将规则和事件传入复杂事件处理引擎。

想要实现本发明所述方法，系统的部署应该按照如图2所示部署，其中复杂事件处理引擎和对引擎进行监控的监听/控制模块部署在服务器端，其中特别指出的是，物联网中间件在整个系统架构中提供设备抽象化的功能与规则管理调度的功能，它与复杂事件处理系统关系紧密，也部署在服务器端。同时，多个客户端可通过网络与服务器端连接，前端监控系统就部署在客户端上，供不同的用户访问使用，对服务器端的复杂事件处理引擎进行监控。

物联网原子事件组成事件流：在系统中，物联网传感器作为底层硬件设备不断地向物联网中间件发送数据，这些数据经过ale服务层的封装进入事件输入适配层，在事件适配层中物联网原子事件是一个java对象，它的示意图如图3所示，其中id指该事件对应的唯一事件编号，epc指rfid标签的epc码，type指传感器对应的实体类型，readtime指该事件产生的时间，reader指产生该事件的传感器id。不断产生的原子事件被传入复杂事件处理引擎，形成事件流。

复杂事件处理引擎的状态监控实施包括：

（1）esper引擎实例化

在系统中，前端用户界面发出启动复杂事件处理引擎的指令，复杂事件处理引擎进行实例化之后开始进入正常运行状态。一个简要的对复杂事件处理引擎进行实例化的过程如图4所示，第一步创建esper引擎的配置信息，并且为esper配置添加事件类型定义；第二步，创建esper引擎实例，提供运行epruntime（引擎实例运行接口）和epadministrator（引擎管理接口）的入口，并且声明引擎实例运行接口，能实现为引擎实例接收数据并发送给引擎处理的功能；第三步，创建statement（复杂事件查询函数）的管理接口实例，并创建一个简单的epl查询语句实例；第四步，为statement实例添加监听。以上四步是一个最简化的esper引擎实例化过程，描述了整个实例过程。

（2）引擎监控流程

在esper引擎成功实例化并且运行正常时，位于监听/控制模块中的监听器对esper引擎的状态进行监听，并且将引擎的状态报告给前端远程访问模块，如图5所示。前端远程访问模块根据引擎的状态信息，向控制器发送指令，对引擎的状态进行更改操作。当引擎发生故障时，事件输入适配层在监听/控制模块的作用下第一时间对事件输入适配层进行影响，将事件流传入到临时数据库中保存，当引擎运行正常后临时数据库中的事件会被存入到永久数据库，临时数据库等待下一次故障时传入的事件流。最后复杂事件处理引擎将符合条件的复杂事件输出。

引擎的灾难恢复实施包括：

当复杂事件处理引擎从灾难中恢复时，系统内部进行的处理流程如图6所示，当灾难发生时，事件输入适配层会将事件流存入临时数据库，控制器会使用与正常启动不同的配置对复杂事件处理引擎重新实例化，包括把数据源从事件输入适配层改为临时数据库，并且创建一个满足条件的缓冲区对实时事件流进行存储，临时数据库中的事件被引擎处理完成之后对缓冲区事件进行加载，如果引擎的吞吐性能足够强，临时数据库中的事件会被很快处理完毕，缓冲区的事件数量很少，不会影响接下来对实时事件流的处理，引擎故障期间错过地复杂事件也被完整的输出，完成引擎的灾难恢复。