复杂事件处理两种技术实现手段的对比，规则语言 VS 持续查询语言

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

了解技术的本质，才能决定什么样的需求场景使用什么样的技术手段。不论是规则语言，还是持续查询语言，我们用复杂事件处理技术替代普通编程语言来实现一些应用，究竟能带来什么好处呢。
（1） 开发时采用声明型语言替代过程式语言。规则语言和持续查询语言都是声明型编程语言，只声明事件的匹配条件和对应的处理动作，整个系统的运行由引擎来执行。这样开发的工作量要小一些，但需要非常准确地了解引擎的工作原理和细节。
（2） 在对大量事件和对象的持续条件匹配和处理的过程中，复杂事件处理产品提供高效的条件匹配，对象查询。这个是应用开发者自己难以实现的部分。
和其他技术一样，复杂事件处理技术不只是产品提供的这些内容。其实更多的是实施的方法论，事件如何分层，如何确定事件彼此的关系，如何来做判断推理，等等。总的来说就是如何把现实世界的一些实体和行为来做建模，用产品工具实现要做的模拟和处理，来得到我们需要的结果。而这部分恰好是没有标准答案的部分，是我们应用开发者在实践中不断思考积累的东西。