事件即事物的状态信息变化,事物之间的作用和动作。复杂事件处理描述的就是系统如何持续地处理这些事件,即系统对变化的持续反应。不论是个体还是系统,都需要从大量的事件中过滤提取,按照既定的处理反应规则做处理。复杂事件处理产品主要采用两种技术手段来完成事件的过滤,判断和处理,即规则语言和持续查询语言。
规则语言定义事件处理的规则,即条件+动作。当某些条件满足时,执行一些处理,一些动作。规则语言定义的规则集合在运行时由规则引擎来执行,当有新的事件和对象产生,或者已有事件和对象变化时,匹配所有规则,满足条件的规则按优先级进入执行队列,按顺序执行规则中的动作。如果该动作的处理导致事件和对象的变化,可能会有新的规则加入执行队列,或者从执行队列中减去一些规则。这个过程会一直执行下去,模拟了一个实体对变化的持续反应。
持续查询语言 CQL 使用类似 SQL 的语法来描述事件和事件反应处理规则。对于内存中大量的外部事件和内部对象, CQL 通过查询语句来做条件匹配,同时提供回调函数,当某些事件或者对象符合查询条件,就调用回调函数做相应的处理。 CQL 提供两种查询方式,快照方式和持续方式。 快照查询只做一次,持续查询类似规则引擎中的规则,只要事件和对象有变化,就执行查询做条件匹配,有匹配上的对象就调用相应的回调函数。这个过程一直会执行下去。同样可以描述对事件的持续反应处理。
从几个方面来比较一下规则语言和持续查询语言。
(1) 两种技术的实现手段。 规则引擎使用RETE网络,将规则集合中的所有条件的所有模式构造成一个匹配树,变化的对象通过这个树进行过滤匹配,判断有哪些条件被满足。匹配树的各个节点会存储在这个节点上满足模式的对象,这样可以在对象变化时不需要重新匹配所有对象,大大加快匹配的速度。持续查询语言使用的是数据库技术,事件和对象相当于表,不论是在内存里还是在文件里。持续查询相当于视图,只要对象有变化,视图里就有对应的体现。通过索引来加快查询匹配速度。抽象一点说这是过滤和查找的对比。打个比方不知道恰当与否,前一个好比是拿着所有的药对着一排药方配药,后一个相当于拿着一张张的药方对着所有的药抓药。
(2) 两种技术的性能。对于这两种技术哪个性能更好,我不知道答案。规则引擎的RETE树通过单个模式节点的连接(joint)来做多个对象多个模式的条件判断,查询语言通过表之间的连接(joint)来做跨多表的查询。谁的性能更好,需要有精通理论的人来研究试验。对我们做应用的人来说感觉当事件和对象很多,但匹配上条件的对象占少数时,使用规则引擎更好些。只是感觉,大家做应用时自己做试验来判断。
(3) 如何选择使用哪种技术。两种技术都能实现对事件对象的持续条件匹配和处理。从开发的角度,一个使用自定义的规则语言,一个使用类SQL的语言,差别也不大;运行时看,对内存的使用都不小。对于这个问题,我现阶段没有好的回答,之后了解得更深些,可能会给一个选择推荐。个人而言,更喜欢规则语言,觉得和现实中描述一个系统的变化反应比较相似。
了解技术的本质,才能决定什么样的需求场景使用什么样的技术手段。不论是规则语言,还是持续查询语言,我们用复杂事件处理技术替代普通编程语言来实现一些应用,究竟能带来什么好处呢。
(1) 开发时采用声明型语言替代过程式语言。规则语言和持续查询语言都是声明型编程语言,只声明事件的匹配条件和对应的处理动作,整个系统的运行由引擎来执行。这样开发的工作量要小一些,但需要非常准确地了解引擎的工作原理和细节。
(2) 在对大量事件和对象的持续条件匹配和处理的过程中,复杂事件处理产品提供高效的条件匹配,对象查询。这个是应用开发者自己难以实现的部分。
和其他技术一样,复杂事件处理技术不只是产品提供的这些内容。其实更多的是实施的方法论,事件如何分层,如何确定事件彼此的关系,如何来做判断推理,等等。总的来说就是如何把现实世界的一些实体和行为来做建模,用产品工具实现要做的模拟和处理,来得到我们需要的结果。而这部分恰好是没有标准答案的部分,是我们应用开发者在实践中不断思考积累的东西。
规则语言定义事件处理的规则,即条件+动作。当某些条件满足时,执行一些处理,一些动作。规则语言定义的规则集合在运行时由规则引擎来执行,当有新的事件和对象产生,或者已有事件和对象变化时,匹配所有规则,满足条件的规则按优先级进入执行队列,按顺序执行规则中的动作。如果该动作的处理导致事件和对象的变化,可能会有新的规则加入执行队列,或者从执行队列中减去一些规则。这个过程会一直执行下去,模拟了一个实体对变化的持续反应。
持续查询语言 CQL 使用类似 SQL 的语法来描述事件和事件反应处理规则。对于内存中大量的外部事件和内部对象, CQL 通过查询语句来做条件匹配,同时提供回调函数,当某些事件或者对象符合查询条件,就调用回调函数做相应的处理。 CQL 提供两种查询方式,快照方式和持续方式。 快照查询只做一次,持续查询类似规则引擎中的规则,只要事件和对象有变化,就执行查询做条件匹配,有匹配上的对象就调用相应的回调函数。这个过程一直会执行下去。同样可以描述对事件的持续反应处理。
从几个方面来比较一下规则语言和持续查询语言。
(1) 两种技术的实现手段。 规则引擎使用RETE网络,将规则集合中的所有条件的所有模式构造成一个匹配树,变化的对象通过这个树进行过滤匹配,判断有哪些条件被满足。匹配树的各个节点会存储在这个节点上满足模式的对象,这样可以在对象变化时不需要重新匹配所有对象,大大加快匹配的速度。持续查询语言使用的是数据库技术,事件和对象相当于表,不论是在内存里还是在文件里。持续查询相当于视图,只要对象有变化,视图里就有对应的体现。通过索引来加快查询匹配速度。抽象一点说这是过滤和查找的对比。打个比方不知道恰当与否,前一个好比是拿着所有的药对着一排药方配药,后一个相当于拿着一张张的药方对着所有的药抓药。
(2) 两种技术的性能。对于这两种技术哪个性能更好,我不知道答案。规则引擎的RETE树通过单个模式节点的连接(joint)来做多个对象多个模式的条件判断,查询语言通过表之间的连接(joint)来做跨多表的查询。谁的性能更好,需要有精通理论的人来研究试验。对我们做应用的人来说感觉当事件和对象很多,但匹配上条件的对象占少数时,使用规则引擎更好些。只是感觉,大家做应用时自己做试验来判断。
(3) 如何选择使用哪种技术。两种技术都能实现对事件对象的持续条件匹配和处理。从开发的角度,一个使用自定义的规则语言,一个使用类SQL的语言,差别也不大;运行时看,对内存的使用都不小。对于这个问题,我现阶段没有好的回答,之后了解得更深些,可能会给一个选择推荐。个人而言,更喜欢规则语言,觉得和现实中描述一个系统的变化反应比较相似。
了解技术的本质,才能决定什么样的需求场景使用什么样的技术手段。不论是规则语言,还是持续查询语言,我们用复杂事件处理技术替代普通编程语言来实现一些应用,究竟能带来什么好处呢。
(1) 开发时采用声明型语言替代过程式语言。规则语言和持续查询语言都是声明型编程语言,只声明事件的匹配条件和对应的处理动作,整个系统的运行由引擎来执行。这样开发的工作量要小一些,但需要非常准确地了解引擎的工作原理和细节。
(2) 在对大量事件和对象的持续条件匹配和处理的过程中,复杂事件处理产品提供高效的条件匹配,对象查询。这个是应用开发者自己难以实现的部分。
和其他技术一样,复杂事件处理技术不只是产品提供的这些内容。其实更多的是实施的方法论,事件如何分层,如何确定事件彼此的关系,如何来做判断推理,等等。总的来说就是如何把现实世界的一些实体和行为来做建模,用产品工具实现要做的模拟和处理,来得到我们需要的结果。而这部分恰好是没有标准答案的部分,是我们应用开发者在实践中不断思考积累的东西。