[0001] 本发明涉及业务流程监控领域，具体涉及一种基于复杂事件处理技术的业务流程实时监控方法。

[0002] 复杂事件处理技术兴起于最近十年，该技术主要用于以事件的方式来处理和分析大量来自于信息系统特别是分布式系统的数据和行为。广义上的事件是指一个特定系统或领域内已经发生的一个事件实例，如订单系统中一个已被处理的订单可以表达为一个订单已处理事件，或者一个订单提交事件；而狭义上的事件特指用于计算的程序实体，如用户界面的某个按钮的按下会触发一个相应按键事件从而引发特定的界面行为，或来自于射频接收器发送给数据收集中心的事件。在本发明中所指的事件主要指建模业务流程行为的可用于计算处理的自定义事件。复杂事件处理通过实时分析和监控持续产生的即时事件来帮助专业人员理解系统的实际运行情况，快速识别特定的系统行为模式并采取相应措施，更加有效地使用事件来增强系统操作、性能和安全。复杂事件处理可以被用于处理许多的信息系统难题，如业务流程的自动化，调度和控制程序，网络监控，性能估计和入侵检测等，目前已存在一些通用的事件处理平台，如Esper、Rulecore、Cagra等。

[0003] 而这些传统的业务流程监控主要通过收集已有流程数据，再通过离线或滞后的数据分析和挖掘算法来达到流程监控的目的，但最终的分析结果往往会因为流程运行场景的迁移和流程数据的时效性而呈滞后性，不利于管理层进行及时的决策。

[0004] 文 献 Using Complex Event Processing for Dynamic Business Process Adaptation(SCC′10)提出了一种基于事件关联规则的精确的事件检测算法，可以支持来自于业务流程的多个事件流。但是很少有工作考虑到大量查询和海量实时事件情况下的业务流程监控系统的性能问题。其中，主要的性能问题体现为在业务流程的上下文中，大量查询会涉及到事件的重叠即子模式共享的情况，因此造成大量事件的重复处理从而增加了时间开销，失效事件(过时，部分匹配失败)的不能及时清理也会造成额外的时间和空间开销。很多特定的事件模式匹配算法如High-Performance Composite Event Monitoring SystemSupporting Large Numbers of Queries and Sources(DEBS 2011)往往只专注于处理单查询，多事件的情况，其在本发明所要解决的问题上做了一定的工作，但该文献所提出的方法只限于处理一些简单的事件模式，如顺序模式，合取模式(&)，析取模式(|)，否模式(！)等.

[0005] 一般的事件模式匹配算法都会把一个模式转换为一个自动机来处理，由于流程监控查询的复杂性，往往会选择非确定性自动机(Nondeterministic Finite Automata：NFA)。往往由于监控需求的复杂性，很多监控查询体现为简单事件模式的混合和嵌套，会造成最终的NFA的容量的增大。而对于监控算法来说，往往对于即时到达的事件是一遍处理的，而这与NFA的工作方式是不兼容的，NFA可能存在大量回溯的情况，因此对于这些算法来说，往往对NFA的工作方式进行了改良使其适应于复杂事件处理，但带来的问题是需要存储大量的部分匹配，NFA越复杂，需要存储的中间状态就会越多。如果不能及时清理失效的中间状态，也会造成极大的事件处理开销。此外，事件共享的程度也决定了处理性能优化的程度，准确地说事件共享对于复杂事件的处理过程的性能提高有着决定性意义，特别是在流程监控的上下文中，很多监控查询都会对某些重要流程分支上的事件给予极大的关注，这些事件的共享决定了在对这些查询进行验证匹配时，不需要重复的处理同样的事件，在处理性能和资源消耗上都有很大的提高。很多工作对于性能问题的处理往往采取隔离的措施加以解决，偏离了整个的事件处理的算法模型，对于整体性能的提高并没有太大的提高，往往会增加算法的复杂性。本发明同等对待事件和查询，一致性地解决了海量事件和大量查询的可扩展性问题。本发明首次考虑了在海量事件、大量查询的情况下具有高性能，可扩展的基于复杂事件的流程监控算法，在事件共享机制和扩展性上都有着较大的提高。

[0006] 鉴于对以上背景技术的理解，本发明的目的，在于提供一种提出基于一定算法模型的于事件匹配，事件共享以及事件清理为一体的流程监控算法，使之在海量事件、大量查询的情况下仍具有较高的性能和扩展性。

[0007] 本发明提出了一种利用复杂事件处理技术对业务流程进行实时监控的方法，包括：

[0008] a.根据业务流程的上下文和事件语义限定流程查询语言；

[0009] b.利用所述流程查询语言，建立基本的复杂事件模式匹配模型；

[0010] c.基于所述基本的复杂事件模式匹配模型建立基于事件的生命周期模型；

[0011] d.基于所述基本的复杂事件模式匹配模型提出跨模式事件共享算法。

[0012] e.基于所述基本的复杂事件模式匹配模型提出事件清理算法；

[0013] 在一个实施例中，所述步骤b至少还包括以下项中的至少一项：

[0014] 基于所述基本的复杂事件模式匹配模型建立算法接收的事件类型；

[0015] 描述事件关联细节的数据结构；

[0016] 限定模式匹配中的部分匹配的数据结构；以及

[0017] 限定用于缓冲事件流的数据结构。

[0018] 在一个实施例中，所述步骤c还包括：

[0019] 以基于复杂事件的流程监控算法对事件流进行单遍扫描和处理并给出匹配结果。

[0020] 在一个实施例中，所述流程查询语言ePMQ的监控框架包括：用户监控接口，基于事件的流程模型，基于事件的流程实例，事件流和独立的事件监控组件。

[0021] 基于本发明所提出的核心算法模型，实现了有效的复杂事件监控算法，对于新到事件和订阅其的复杂事件的匹配调度过程保证了其有序性和准确性，每一个新到事件都得到了正确的处理，每一个查询都确保其订阅的事件都进行了相应的匹配，取得了实时性和准确性的平衡。本发明给出了一种高效的基于引用计数策略的事件清理算法，并保证了同现有算法模型的兼容，使得监控算法和清理算法的相互协作，互不干扰。

[0022] 本发明对于大量流程监控查询中存在的事件共享情况，提出了共享sub-pattern的概念，并给出了尽最大努力的共享挖掘算法，根据共享sub-pattern的粒度层次，由细到粗地挖掘出了所有可能的共享情况，并保证了同现有算法模型的兼容。

[0023] 总而言之，基于依据本发明的复杂事件模式匹配模型而实现的高适应性流程监控算法，拥有高效的事件清理及共享机制。本发明能够有效支持实时的业务流程监控，处理性能高，伸缩性强，即使在海量事件、大量查询的情况下仍具有较大的吞吐率。

[0024] 通过参照附图阅读以下所作的对非限制性实施例的详细描述，本发明的其它特征、目的和优点将会变得更明显：

[0025] 图1示出了基于复杂事件的流程监控框架；以及

[0026] 图2示出了复杂事件模式匹配算法的工作模型和关键数据结构

[0027] 图1示出了基于复杂事件的流程监控框架。在该图中，流程查询语言表示为ePMQ，由于该查询语言是基于业务流程上下文环境的模式查询语言，因此需要对基于复杂事件的业务流程模型进行定义和说明，以保证ePMQ的领域特点和语义的完备性。图1给出了本发明所基于的一个基于复杂事件的业务流程监控模型。在图1所展示的基本的基于事件的流程监控框架主要包括5部分：用户监控接口，基于事件的流程模型，基于事件的流程实例，事件流以及独立的事件监控组件。

[0028] 本发明对于事件驱动的流程监控框架基于一个简单的假设：对于流程图中的每个节点，都存在一个相应的事件(Business Event：BE)，一旦流程运行时经过此节点就会即时生成一个该事件的实例。每一个BE涵盖了其宿主节点运行时的流程当前状态信息如触发该节点的用户信息，它所引用的数据字段以及时间戳等。流程运行时生成的事件都会流入唯一的事件流。其中，一个事件(BE)可以表示为一个三元组BE(z，p，t).其中z代表事件类型，p代指事件的内容，t即指事件产生的时间。为了建模当前流程的运行状态，p一般可以解释为一个拥有一定字段的多元组(t1，t2，...tn)，每一个字段代表一项信息，如当前流程的ID，流程实例的ID，用户ID，实际引用的数据字段。

[0029] 一个完整的基于事件的流程模型不仅要涵盖流程中所有可能的操作和操作之间的执行顺序，还应包括附属于流程中每个节点的BE的集合。

[0030] 而一个基于事件的流程模型可以看作是一个五元组PM(S，s0，F，E，T).其中S指流程所应包括的状态集，每一个节点可以被看作是一个状态，流程图中的控制网关可以看作是状态之间的迁移。S0指流程的起始状态，F指终止状态集，E指该流程所支持的BE的集合，而T指流程模型中所有状态迁移。不同的流程实例映射为流程运行时的不同的视角，即所经过的不同状态，所经历的不同状态迁移以及实时产生的不同事件序列，对于一个基于事件的流程模型M，其可能的流程实例被限定如下：

[0031] 此外，一个基于事件的流程实例是一个3元组PI(pM，pE，pT)，其中pM指PI所属的流程模型，pE指实例运行时产生的事件实例集合，pT指流程运行时所隐含的不同的状态迁移过程。

[0032] 事件流既作为流程实例所产生的事件序列的缓冲，也作为事件监控组件的唯一事件输入流，其限定如下：

[0033] 而事件流则表示为： .其中，ei作为一个事件实例，属于PI.pE

[0034] 而本发明所提出的流程查询语言ePMQ正是作为用户监控接口的一个实现，ePMQ是一个类似于SQL的声明式语言，类似于已有的数据流查询语言(如STREAMS的CQL)和复杂事件语言(Esper的EPL).它提供了简单但有效的语义以支持适应各种流程监控需求的查询的订制。ePMQ的概要结构如下：

[0035]

[0036] Pattern子句用于声明事件模式表达式，一个完整的模式表达式可以表示为一组事件类型(简单事件类型或复杂事件类型)通过各种事件算子的连接而形成的一个特定的事件模式表达式。一个简单的顺序事件模式如e1；e2；e3，其中e1，e2，e3即为监控查询所感兴趣的事件类型，而’；’代表了这是一个顺序模式，当事件流中连续出现e1、e2、e3三种类型的事件实例时，即代表pattern子句所限定的事件模式有了一个成功匹配。

[0037] As子句所限定的是该查询的用户自定义名字，既用于该查询的标识，每一个查询的输出也可以看做一个特定复杂事件类型的实例产生，因此该子句所定义的名字也可以出现在另一个查询的Pattern子句中，通过多个查询的组合以适应某些复杂的监控场景。特别是涉及流程/子流程的情况，往往一个查询无法或很难描述监控场景，这时可以选择一个子流程一个查询，这些查询所输出的事件类型再出现在一个层次更高的查询中。本发明对于查询的输出只是规定一个相应复杂事件产生，至于该事件生产时的触发行为不属于本发明范畴。

[0038] Process子句主要用于声明该查询所依赖的特定业务流程。Where子句类似于SQL中的Where子句，主要用于声明Pattern子句中所出现的事件或事件之间的属性限制，如e1.t2＞e2.t2等。Within子句主要用于声明时间窗口，以规定模式中的事件实例必须满足的时间范围限制。

[0039] 事件算子是ePMQ的一个核心元素，主要用于定义一个监控查询所对应的事件模式中事件之间的具体关联模式。业务流程监控应用中可能的事件模式是非常丰富和复杂的，为了能清晰的表达各种复杂监控查询，ePMQ提供了一系列事件算子来支持各种监控查询的声明。

[0040] 紧连顺序算子(；)：A；B.事件B必须紧挨着事件A出现，任意其他类型事件不能出现在A与B之间。

[0041] 松散顺序算子(；；)：A；；B.事件B必须出现在A之后，但允许任意其他事件出现在A与B事件。该算子的重要作用在于对于某些流程监控查询，它只关注流程是否经过了某条子路径，而不关注路径上的实际产生事件是什么，只要声明A为该路径的起始事件，B为该路径的结束事件。

[0042] 并发算子(&)：A&B.事件类型A和B在一个同等的时间窗口内都有实例产生，两者的产生顺序并没有严格要求，只要在特定时间窗口内都发生即可。这对应于业务流程中的并发网关及其分支。

[0043] 析取算子(|)：A|B.在一个时间窗口内，事件A或B发生。该算子对于业务流程中的析取网关，分支中总有一条会在流程执行时经过，意味在该分支上的事件会被生成。

[0044] 基数算子({number[，number]|number＝{0，1，...&&}})：A{3}，A{1，3}..事件A重复发生多次，括号里即为重复次数或范围.该算子对应业务流程里的循环网关。

[0045] 否算子(！)：！A.事件A发生时，该算子返回假(False)。出现在该算子中的事件类型所包含的实例在模式匹配时若被检测到，标志着当前模式匹配失败。该算子主要用于监控流程里的一些异常情况。

[0046] 接下来介绍复杂事件模式匹配模型。图2示出了复杂事件模式匹配算法的工作模型和关键数据结构。每个业务流程事件被转化为一个原子事件(Primitive event，简称PE)，每个ePMQ查询被转化为一个复杂事件(Composite event，简称CE)，查询的处理工作最终被转变成一个类似的事件发现工作，这使得eBPmon成为一个纯粹的以事件为中心的监控引擎。EventPool是储存这些事件的地方，并且每个事件都被赋予一个状态语义，这使得在处理不停到达的事件和查询的情况下可以更高效地发现事件，包括原子事件和复杂事件。CeTree属于一个基于树的描述复杂事件层次结构的数据结构，它维护EventPool内事件之间的关系，得益于此，以及之前定义的事件状态转换，我们可以提出高效的事件发现组件。对于发现原子事件，只要识别出准确的事件类型，而对于发现复杂事件，就要发现所有其内部的事件，匹配事件的模式，并且这些事件的属性要满足约束条件。为便于进行实时的模式匹配，我们采用了一个叫CePmatch的数据结构去记录相应的复杂事件的部分匹配状态。

[0047] 在eBPmon中，事件可以分为2个抽象类型：原子事件(PE)和复杂事件(CE)。所有的业务流程事件属于原子事件，而复杂事件是一种表示多个事件之间关系的特殊的事件。每个由运行中的流程实例产生的事件为原子事件。一个原子事件是一个4元式，有PE＝(z，p，st，et)，st和et从业务流程事件的t属性取值，所以对每个原子事件ex来说，ex.st＝ex.et。这个设计在这个事件架构中很关键，因为它统一了原子事件和复杂事件的时间戳表达。一个复杂事件是一个5元式，有CE＝(z，Q，C，st，et)，其中，z指复杂事件的事件类型，Q＝{e1，e2....en}是相关的原子事件或其它复杂事件的集合，C指CE所蕴含的内部事件之间的关联关系，st是这个复杂事件的开始时间，et是结束事件。st和et都可以从Q中得到：

[0048] st＝Min{ei.st|i＝1，2....n，ei属于Q}；

[0049] et＝Max{ei.st|i＝1，2....n，ei属于Q}.

[0050] 在(st，et)的时间范围内，复杂事件包含了其所有的子事件，每个ePMQ查询都可以被视作一个复杂事件。

[0051] CeTree&SList

[0052] 可见，一个复杂事件是一个嵌套结构，将很多事件关联起来。这个内部关联只关注该复杂事件下的事件类型的组织结构，为了对其进行建模，我们设计了一个多叉树，叫做Correlation Tree(CeTree)，不考虑数值约束和时间约束。在这个Correlation Tree中，叶节点都是原子事件，内部节点是另一个嵌套在里面的复杂事件，根节点必须是一个复杂事件。显然，Correlation Tree维护这复杂事件的层次关系，可以用来建立下文所述的Subscriber List。

[0053] Subscriber List(SList)：这个SList维护了每个事件的订阅者，避免了在CeTree中动态查找它们，对于Correlation Tree，事件的订阅者可以看做树中的父节点。Slist可表示为一个2元式(cid，ce_list)，期中cid是event pool中事件的类型，ce_list是由在该事件在CeTree中父节点所代表的复杂事件的类型所组成的链表。

[0054] CePmatch复杂事件的部分匹配

[0055] 为简化和高效，一般的ePMQ查询处理过程有3个连续的子任务组成：模式匹配，时间约束评价和数值约束评价。事件流中的一组事件只有通过了全部3个评价才能产生一个成功的ePMQ查询的模式匹配，生成一个复杂事件实例。这种分开处理的安排源于一个清楚的认识，那就是如果将时间、数值约束和模式的语义混合起来会生成一个非常复杂的NFA，有时将不具备可操作性。

[0056] 为了管理NFA的部分匹配，我们用一个叫CePmatch的数据结构记录当前的部分匹配。一个复杂事件的正式的CePmatch是一个3元式，有CePmatch(CE)＝(start_time，current_state，{event_list})，其中start_time是CePmatch激活的事件，与其开始事件的开始时间st相等，而event_list是将这个NFA推动至当前状态(current_state)的事件列表。事件列表以事件的结束时间et降序排列。一次NFA的状态迁移可被视为一次CePmatch的计算。例如，一个复杂事件的模式是一个顺序的模式(e1；e2；e3；e4；e5)，其当前的CePmatch是(e1.st，3，{e1，e2，e3})，其中e1，st指这个CePmatch的开始时间，数字3指NFA现在在状态3，事件列表{e1，e2，e3}表示了推进匹配过程的过往事件。所以，当一个事件实例e4到达，这个CePmatch将被更新为(e1.st，4，{e1，e2，e3，e4})。事实上，一个复杂事件的运行中的NFA可被描述为一个CePmatch的创建和维护。但是对于一个查询来说，任何一个触发其NFA的开始事件的到来都会生成一个对应的CePmatch，因此一个运行的监控查询的事件模式的匹配可能存在大量CePmatch的更新和维护，每一个CePmatch的状态迁移都是依据监控查询所对应的NFA的状态迁移语义。由于NFA存在回溯的情况，而对于事件处理来说，事件往往是一遍处理，过多的回溯会造成大量旧事件的积累，不利于系统性能的提高，为此在监控算法中，NFA会被转换为一个DFA，每一个新事件的到来对于CePmatch的更新都是确定的，不存在回溯的情况。

[0057] Event Pool

[0058] 本节我们将描述event pool的内部数据结构，涵盖了一些关键方面例如事件存储，事件状态管理以及事件和SList、CePmatch这些辅助数据结构之间的关系。

[0059] 形式语义

[0060] event pool可被视为一个表的结构，其中每个事件都是一个单独的记录项，事件项是一个7元式：Event_Item(id，type_id，composite_type，st，et，state，payload)，解释如下：

[0061] ID：id是事件在event pool中的全局id

[0062] Type_Id：表示事件的全局事件类型

[0063] Composite_Type：表示事件是否是复杂事件，0为原子事件，1为复杂事件[0064] Payload：根据不同的Composite_Type属性，事件的Payload也有所不同，一个原子事件项的Payload等于PE.p，而一个复杂事件的payload由3部分组成：CE.Q，CE.q和一个指向其CePmatch列表的指针组成，CePmatch列表中的CePmatch由其开始时间戳降序排列。

[0065] st：等于[PE|CE].st；et：等于[PE|CE].et；state：之前提到，一个事件有4个状态：创建(1)，初始化(2)，激活(3)，死亡(4)

[0066] 事件状态(State)语义

[0067] 在event pool中，每个事件都经历由4个状态组成的生命周期。

[0068] 创建(1)：一个事件被标记为“创建”意味着一个新的事件在event pool中生成。事件可能来自于两个来源：1.从事件流中到达的事件，是无状态的；2.由BPM分析师新插入的ePMQ查询。当一个事件在该状态下时，事件项的属性还没被完全设置好。只有id，type，composite_type和state属性填入表中，其余未设置。

[0069] 初始化(2)：一个事件被标记为“初始化”意味着这个事件项被完全设置好并且可以参与其订阅者的模式匹配。事件的数据项都被完整的设置了。

[0070] 激活(3)：当一个事件在这个状态意味着这个事件实际上正在参与一个其订阅者复杂事件的部分匹配。此时这个事件的id可在某些CePmatch中找到。

[0071] 死亡(4)：当一个事件进入这个状态意味着它的终结，之后它将被清理。如果一个事件不满足时间约束或一个复杂事件匹配了并结束了它在event pool中的使命，这些事件会被标记为“死亡”。定义这个状态非常有利于节省存储空间，因为我们可以清理标记为这个状态的事件。

[0072] 事件状态迁移语义：状态1-＞2：这个迁移取决于标记为状态1的事件类型。如果是原子事件，并且存在订阅它的复杂事件，那么它直接由状态1迁移至状态2，继而这个事件的表项被初始化。如果是复杂事件，迁移只会发生在成功地“发现”了这个复杂事件的情况下，并且在状态迁移之后该复杂事件会继续留在event pool中等待参与订阅其自身的其他复杂事件的模式匹配过程，该复杂事件在event pool中的所有未初始化字段也将被初始化。状态2-＞3：这个状态迁移发生在事件成功地扩展了或创建了一个复杂事件的新的部分匹配时。

[0073] 状态3-＞4：这个状态迁移发生在这些情况下：1.它是一个原子事件，它参与的某个复杂的部分匹配失败，同时它对其他事件没有意义(没有订阅者，过时)；2.一个复杂事件超出了滑动时间窗口的限制，这意味着它以一个未完成的匹配终止。

[0074] 状态1-＞4：这发生在一个“无意义”的新事件上。对于原子事件，意味着没有复杂事件订阅它，对于复杂事件，意味着在一个有效的时间窗口中，从未“发现”(匹配)一个这样的复杂事件。

[0075] 状态2-＞4：事件没有参与到任何复杂事件的部分匹配中，一种情况是订阅它的复杂事件不再属于一个有效的时间窗口，或者它的所有订阅者已经在状态2中处于匹配完成的情况。

[0076] 基于复杂事件的流程监控算法

[0077] 本发明基于前面介绍的复杂事件模式匹配模型中涉及的事件模型以及其他关键数据结构(CeTree，SList，CePmatch和EventPool)处理事件流中不断到达的新事件和新的监控查询。因此，本算法主要分为两个并行的部分：查询处理算法和事件处理算法。

[0078] 查询处理算法主要负责处理用户提交的ePMQ查询，并生成其对应的CeTree，再根据CeTree更新全局的SList.同时根据该查询会生产一个相应的复杂事件实例在event pool中，其状态被置为1，其工作过程如下：

[0079] 接受用户新的查询，设为Qe

[0080] 提取出Qe中的pattern子句和As子句，根据As子句中声明的字符串生成一个新的事件类型Eq.提取出pattern子句中所包含的事件类型集合Se，生成事件类型Eq的CeTree，然后根据新生成的CeTree，将其中所蕴含的事件订阅关系更新到事件订阅表SList中。若订阅关系已存在，则忽略，否则加入到SList中。复杂事件Eq的事件关联语义得以存储下来。

[0081] 根据从Qe中提取的pattern子句生产相应的NFA，再将NFA转换成DFA.其中，每一个Eq所订阅的事件都是DFA状态迁移的一个条件。

[0082] 将DFA的终节点Nend变成中间节点，再附上两个顺序相连的节点Nend1和Nend2.提取出Qe中的where子句将其中所蕴含的事件属性限制转换为从Nend到Nend1的状态迁移条件。而within子句中所蕴含的时间窗口限制变为从Nend1到Nend2的状态迁移条件。因此，Nend2成了DFA新的终节点。最终生产的DFA会和事件类型Eq绑定起来。

[0083] 根据已计算出的事件类型Eq，CeTree和查询匹配所对应的DFA生产一个事件类型为Eq的复杂事件于EventPool中，其初始状态为1，并根据当前状态的语义进行局部初始化。

[0084] 查询处理算法的工作主要是将用户提交的监控查询映射到复杂事件模式匹配模型中的各个组件中去，如生成事件类型，用于事件模式匹配的DFA，在event pool中的初始化等，以便于以后的自动匹配过程。事件处理算法就是基于查询处理处理算法得工作进行事件模式匹配的自动化运行，保证event pool中的事件能参与到作为其订阅者的复杂事件的匹配过中去，并确保匹配过程的正确性和有效性。

[0085] 事件处理算法主要分为三个阶段：通知阶段，匹配阶段，响应阶段。

[0086] 通知阶段：当流程运行时实时更新的事件流中有新的事件ex到来时，查询SList，若不存在订阅者，忽略该事件。反之，在event pool中搜索属于订阅者事件类型的事件实例，若不存在状态为’创建’的事件实例，忽略该事件；否则在event pool中插入该事件，状态为’创建’.若新到事件为原子事件，待初始化完成后，状态置为’初始化’.然后该事件与订阅它的事件实例集合Se一起进入到下一阶段

[0087] 匹配阶段：对Se中的每一个事件ey，进行以下验证过程：查找到与ey绑定的DFA Fey。若ex是Fey的起始状态，则生成一个部分匹配CePmatch，并按照相应的语义初始化之，ex的状态更新为‘激活’。否则，则对ex所拥有的CePmatch集合中的每一个CePmatchCPy，若ex能造成当前部分匹配CPy的状态迁移，则将ex更新进CPy中，ey的状态更新为’激活’。若ex造成CPy更新为一个完全匹配，则意味着复杂事件ey的事件模式匹配成功，ex和ey一起进入下一阶段。

[0088] 响应阶段：将ey进行完全初始化，并置状态为’初始化’.查询SList，若ey存在订阅者，则将ey插入到事件流的前端，这时ey被看作一个新的事件按照(1)-(3)的过程进行处理。若不存在其他订阅者，则触发相应的外部行为，然后将ey的状态置为’死亡’.[0089] 事件清理算法

[0090] 本发明提出的事件清理算法，主要是基于事件的生命周期和引用计数策略来清理在event pool中积累但已过时的事件(包括简单事件和复杂事件)。事件清理涉及到标识出哪些事件是需要被清理的，以及如何清理。基于事件的生命周期的状态定义和状态迁移语义，一旦事件的状态为’死亡’时，该事件是需要被清理的，清理过程也是很简单的，只需要销毁该事件在event pool中的实例即可。但一般存在的问题是有些事件被处理后，往往因为参与到其他事件的匹配过程，具体体现为某个复杂事件的CePmatch的已匹配事件集合event_list引用了该事件，而需要继续留存在event pool中以备该部分匹配成为完全匹配时需要进行的值约束验证和时间窗口限制，而往往存在的问题是这些部分匹配不知道什么时候结束，所以不能准确的保证一些应被清理的事件的状态被置为’死亡’。一般的事件清理算法，往往通过定时扫描event pool，对每一个状态不为’死亡’的事件进行验证以判断其是否应被清理，而验证过程往往需要去探测订阅该事件的复杂事件所有已存的CePmatch，查看是否该事件存在其event list中，这一过程是非常耗时且往往是徒劳无功的，特别是在海量事件的情况下。本发明基于引用计数策略提出的事件清理算法，保证在极小的代价下准确识别出应被清理的事件，并及时清理之。

[0091] 本发明对event pool中的每一个事件增加一个引用计数字段’RC’，则加入RC之后的event pool：

[0092] 对于事件的引用计数RC的维护策略如下：

[0093] RC的初始化：当事件第一次加入到event pool时，并且状态更新为为’初始化’时，RC初始化为0.

[0094] RC的+1：当事件ex参与到某个复杂事件的部分匹配cp，体现为ex属于cp.event_list时，RC++；当事件ex成为某个匹配成功的复杂事件ey的内部事件时，RC++.[0095] RC的-1：当部分匹配因失败或完全匹配因被清理时，所有其event_list中的事件的RC--；当复杂事件ey需被清理时，其ey.Q中的所有事件的RC--。

[0096] 而基于引用计数RC的的事件清理方法基于一个简单的原则，若事件的RC为0时，其状态应为’死亡’，是需要被清理的。所有事件状态为‘死亡’的，其RC也应为0.具体的清理方法如下：

[0097] 搜索event pool中所有RC值为0的事件，将其放入到待验证事件集合Se中。对Se中的每个事件ep进行如下验证：若事件状态为’创建’，进入(2)；若事件状态为’初始化’，进入(3)；若事件状态为’激活’，进入(4)

[0098] 根据事件状态迁移模型中状态1-＞4的迁移语义，若ep满足该语义，其状态更新为置为’死亡’，进入清理过程：由于该事件状态为’创建’，若为简单事件直接释放掉即可，若为复杂事件，还需要清理掉其内含的CePmatch链表，再清除每一个CePmatch时，需要对其event_list所引用的事件的RC进行减一操作.

[0099] 根据事件状态迁移模型中状态2-＞4的迁移语义，若ep满足该语义，其状态更新为置为’死亡’.选入清理过程：由于该事件状态为’初始化’，对于简单事件，直接释放掉即可，对于复杂事件对于其ep.Q中所引用的内部事件的RC进行减一操作.

[0100] 根据事件状态迁移模型中状态3-＞4的迁移语义，若ep满足该语义，其状态更新为置为’死亡’.进入清理过程：由于事件状态为’激活’，若为原子事件直接清理，若为复杂事件，还需对其ep.Q中所引用的内部事件的RC进行减一操作..

[0101] 跨模式事件共享算法

[0102] 该算法旨在挖掘出所有监控查询中可共享的sub-pattern，将这些挖掘出的sub-pattern从其宿主pattern中抽离出来形成一个独立的复杂事件Es，所有共享这个sub-pattern的宿主事件都将变成订阅Es的复杂事件。这样Es的成功‘发现’所消耗的处理资源将被所有其订阅者所共享，当类似的Es越多时，共享的覆盖率越广，所导致的性能提高也越明显。本发明基于现有算法模型所提出的跨模式事件共享方法如下，该共享算法并没有破坏现有的算法模型，反而是充分利用了算法的基本模型，当共享完成之后，前面介绍的复杂事件监控算法并不需要做出修改：

[0103] 本算法所基于的基本数据结构为待共享结果集PreEventSet(sp，event_list)，其中sp是当前所有监控查询中挖掘出来的某个sub-pattern，event_list是这个拥有这个sp的所有复杂事件的集合。本算法的工作就是对于当前复杂事件集得出其PreEventSet，然后基于这个PreEventSet进行具体的共享工作。步骤(2)-(3)给出了计算PreEventSet的过程，步骤(4)给出了基于算法模型的具体的共享过程。

[0104] 粒度最小的sub-pattern往往是类似于A；B，A；；B，A&B等以事件算子为单位的，粒度更大的sub-pattern往往是基于这些粒度最小的sub-pattern的组合和嵌套。因此算法的这一步是找出这些粒度最小的sub-pattern，值得注意的是，A；B这种结构的sub-pattern不在第一次sub-pattern搜索的范围之内，因为，参与事件较少的顺序pattern对于自动机的复杂度的影响是不大的。本发明基于公共子串搜索算法，把每一个ePMQ查询中的pattern子句中的粒度最小的sub-pattern搜索出来，对于每一个粒度最小的sub-pattern和其宿主复杂事件集合初始化当前PreEventSet，命名为PES.执行完步骤(4)后，接着执行步骤(3)。

[0105] 该步骤是对于(2)中得到的基于最小粒度的sub-pattern的PES，进一步挖掘更高层次的sub-pattern.该步骤仍是基于公共子串搜索算法，但这次搜索的字串将不作限制，凡是搜索出来的公共字串都成为一个新的sub-pattern，同时与当前PES中的共享该sub-pattern的复杂事件一起更新PES.

[0106] 对于当前PES中的每一项Item_PES，item_PES.sp形成一个独立的复杂事件Esp，拥有其自己的事件类型，item_PES中的每一个事件订阅该Esp，同时新的订阅关系也被更新进其CeTree和全局的SLIst中。

[0107] 本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；不定冠词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。本专利覆盖在字面上或在等同原则下落入所附权利要求的范围的所有方法、装置和产品。