面向物聯網的復雜事件處理引擎狀態監控與災難恢復方法與流程

本發明涉及物聯網傳感器網絡、物聯網中間件、復雜事件處理等技術領域，具體涉及復雜事件處理引擎的狀態監控及引擎災難恢復方法。

背景技術：

物聯網傳感器網絡是一種由獨立分布的節點以及網關構成的傳感器網絡。傳感器的類型多種多樣，所以物聯網能夠促進各種應用在不同領域的發展，例如家居自動化、工業自動化、醫療援助、移動醫療保健、老年人輔助、智能能源管理、智能網格自動化交通管理等等其他方面。在物聯網傳感器網絡中，安放在不同地點的傳感器節點不斷采集著外界的物理信息，如溫度、聲音、震動等。傳感器網絡的每個節點都能夠實現采集，數據的簡單處理，還能接收來自其他節點的數據，并最終將數據發送到網關。開發者或工程師可以從網關獲取數據，查看歷史數據記錄或進行分析。

物聯網中間件技術是在當前物聯網環境下，解決設備異構、信息海量、數據類型多等問題的通用服務平臺，實現對物的管理、交互和信息處理等功能。物聯網中間件處于系統架構的中間部分，介于物聯網底層硬件/操作系統和上層應用程序之間，其作用是減輕上層應用的數據處理負擔，屏蔽物聯網環境中的異構性，提高可移植性。當前物聯網環境中，使用最廣泛的傳感器設備是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所示，當災難發生時，事件輸入適配層會將事件流存入臨時數據庫，控制器會使用與正常啟動不同的配置對復雜事件處理引擎重新實例化，包括把數據源從事件輸入適配層改為臨時數據庫，并且創建一個滿足條件的緩沖區對實時事件流進行存儲，臨時數據庫中的事件被引擎處理完成之后對緩沖區事件進行加載，如果引擎的吞吐性能足夠強，臨時數據庫中的事件會被很快處理完畢，緩沖區的事件數量很少，不會影響接下來對實時事件流的處理，引擎故障期間錯過地復雜事件也被完整的輸出，完成引擎的災難恢復。