Drools Fusion介绍.docx

droolsfusion（3）2010-12-02 23:07五、事件处理模式(Event Processing Modes)Drools支持2种事件处理模式：云模式(Cloud Mode)和流模式(Stream Mode)1.云模式(Cloud Mode)云(Cloud)处理模式是默认的处理方式。在云模式下，不会区分事实和事件，都看成是事实。（1）没有时间的概念。尽管事件在插入引擎被赋予了时间戳，也不能判断该事件“多大了”，因为没有“现在”的概念。滑动窗（sliding windows）基于“现在”的概念，所以在云模式下无法使用。（2）无序的事件云。由于事件无序，没有自动的生命周期管理，需要像正常的事实一样显示的删除事件。云模式虽然是默认的执行模式，我们也可以配置它：KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();config.setOption( EventProcessingOption.CLOUD );等同系统属性配置：drools.eventProcessingMode = cloud2.流模式(Stream Mode)当处理事件流的时候需要选择流处理模式。在流模式下：(1) 插入到引擎里的事件必须是时间顺序的。(2) 引擎强制性的和使用的会话时钟session clock同步。配置流模式：KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();config.setOption( EventProcessingOption.STREAM );等同配置系统属性：drools.eventProcessingMode = stream使用流(STREAM)模式，引擎有时间流和现在的概念(通过读取Session Clock的时间戳)，提供了以下3种支持：(1) 滑动窗的支持(2) 自动的时间生命周期管理(3) 使用消极模式(Negative Patterns)自动的规则延迟3.会话时钟(Session Clock)在流模式(Stream mode)中的作用在云模式下，会话时钟只有一个作用，就是给插入到working momery 的事件赋予时间戳的值(如果规则没有定义时间戳属性)在流模式下，会话时钟负责维护当前时间戳，基于当前的时间戳，引擎根据事件的年龄计算所有时间运算，从多种源同步流，安排未来任务等等。4.流模式(in Stream Mode)中的消极模式(Negative Patterns)消极模式在流模式和云模式意义是不同的。在云模式下，所有的事实和事件都是预先知道的，消极模式立即计算执行/a rule that activates immediately upon matchingrule Sound the alarmwhen $f : FireDetected( ) not( SprinklerActivated( ) )then / sound the alarmend在流模式下，带有时间约束的消极模式可以要求引擎等待一段时间后激活规则。/a rule that automatically delays activation due to temporal constraintsrule Sound the alarmwhen $f : FireDetected( ) not( SprinklerActivated( this after0s,10s $f ) )then / sound the alarmend六. 滑动窗(Sliding Windows)滑动窗是一种选择事件范围的方式。滑动窗有2种实现方式：滑动时间窗(Sliding Time Windows)，滑动长度窗(Sliding Length Windows)。注意：滑动窗只有在引擎为(STREAM)流模式下才是可用的1.滑动时间窗(Sliding Time Windows)滑动时间窗(允许我们的规则)仅仅匹配发生在最近X时间单元的事件。例如，如果只关心最近2分钟的股票行情，模式(pattern)可以这样写：StockTick() over window:time( 2m )更复杂的例子：如果最近10分钟从传感器读来的温度高于最大的临界值，发出警报。rule Sound the alarm in case temperature rises above thresholdwhen TemperatureThreshold( $max : max ) Number( doubleValue $max ) from accumulate( SensorReading( $temp : temperature ) over window:time( 10m ), average( $temp ) )then / sound the alarmend2.滑动长度窗(Sliding Length Windows)滑动长度窗(允许我们的规则)仅仅匹配发生在最近X个的事件。例如，如果只关心最近10个IBM股票的行情，模式(pattern)可以这样写：StockTick( company = IBM ) over window:length( 10 )更复杂的例子：如果最近100次从传感器读来的温度高于最大的临界值，发出警报。rule Sound the alarm in case temperature rises above thresholdwhen TemperatureThreshold( $max : max ) Number( doubleValue $max ) from accumulate( SensorReading( $temp : temperature ) over window:length( 100 ), average( $temp ) )then / sound the alarmend七.Knowledgebase分割(Partitioning)(注意：这是个实验性的特征，将来可能会发生变化)传统的Rete算法通常一个线程在执行，也是Drools默认的。但是，该算法本身是可平行(化)的。Drools执行的ReteOO算法通过Knowledgebase分割支持粗粒度的平行执行。当这个选项可用，Knowledgebase分割成若干个独立的区域，然后用线程池通过这些区域传播事实。该实现保证最多有一个线程在给定的一个区域执行。要点：这个特征只在LHS平行执行可用，不会改变规则激活行为。1.平行执行在什么时候有益：(1)多处理器(2)knowledge session处理大量的事实(3)规则的LHS计算量大(4)knowledge base包含数百或者更多的规则如果以上条件都符合，这个特征可能会提高knowledgebase计算总性能。2.配置Knowledgebase分割/enabling multithread evaluation (partitioning)KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();config.setOption( MultithreadEvaluationOption.YES );等同系统属性配置：drools.multithreadEvaluation = 3.多线程管理配置线程池:/setting the maximum number of threads for rule evaluation to 5KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();config.setOption( MaxThreadsOption.get(5) );等同系统属性配置：drools.maxThreads = 配置默认值是3，负数值表示在Knowledgebase中有多少分区，引擎就会产生多少线程，使用负数值是很危险的。八.事件的内存管理要点：自动的事件内存管理只有在引擎为Stream模式下才有效。引擎在Steam模式下的好处之一是引擎能够根据时间约束检测出不再匹配任何规则的事件，然后引擎可以没有负作用的安全地回收事件并释放其相关的资源。引擎有2种基本方式计算一个事件有效期：(1)显式，使用过期(expiration)策略(2)隐式，分析事件的时间约束1.显式的过期偏移量(有效期)/explicitly defining an expiration offset of 30 minutes for StockTick eventsdeclare StockTick expires( 30m )end当StockTick事件持续30分钟后，如果没有规则需要该事件，引擎将自动的回收该事件。2.推知的过期偏移量/example rule with temporal constraintsrule correlate orderswhen $bo : BuyOrderEvent( $id : id ) $ae : AckEvent( id = $id, this after0,10s $bo )then / do somethingend引擎需要保存BuyOrderEvent 10秒以匹配AckEvent。BuyOrderEvent隐式的过期偏移量是10秒，AckEvent隐式的过期偏移量是0。引擎会分析整个Knowledgebase，找出每个事件类型的过期偏移量。当隐式过期偏移量和显式过期偏移量冲突时，引擎会选择2个值中最大的1个DroolsFusion介绍文章来源Michal Bali的DroolsJBoss Rules 5.0 Developers Guide一书中CEP的章节部分内容。笔者翻译了过来，供大家了解DroolsFusion，CEP的概念。规则通常或多或少操作于静态数据集（事实）。然而，对于一些系统，有必要定义时间关联的事实。他们通常叫做复杂时间处理（CEP）或者是事件流处 理（ESP）。DroolsFusion，从5.0版本开始，提供了滑动窗体（sliding windows）,时间运算符（temporal operators），类型声明（type declarations）于一体的支持。CEP 和 ESPCEP 和 ESP 是 事件驱动架构（Event Driven Architecture）处理模式(更多关于事件处理架构的信息：/bmichelson/2006/02/eventdriven_arc.html)。 这个架构的一个主要的好处就是提供了组件的松耦合。一个组件可以发布正在执行的动作事件，其他组件可以订阅/监听这些事件。发布者和订阅者不知道对方的存 在。一个订阅监听事件者不关心事件的来源。相似的，产生事件的生产者也不知道任何监听这些事件者的任何事情。一些编排层处理实际的订阅、发布之间的装配。一个事件代表有意义状态的改变。它通常由一个事件头和事件体组成。事件头包含了名称，发生时间，持续时间等元信息。事件体描述了发生了什么。例如，如果一个银行交易被处理，事件体应该包含交易的ID，交易数量，本人帐号，转账帐号等。CEP 处理复杂事件。一个复杂事件是简单事件的集合。比如，一系列的巨额提款激发可疑交易事件的发生。一个复杂事件的发生是由一系列简单事件的引导形成的。ESP 是更实时(real-time)的大量事件处理。例如，根据时间计算实时平均交易量。更多关于CEP和ESP的信息：/、由作者Prof. David Luckham编写的The Power of Events。这本书被认为当今研究和发展CEP的里程碑。现在有很多完整的CEP/ESP 引擎，包括商业的和开源的。DroolsFusion支持事件以增强编程式规则。它使用Rete算法并提供一个可选的引擎。DroolsFusionDroolsFusion 是业务逻辑集成平台（Business Logic IntegrationPlatform）一部分的一个Drools模块。Drools事件处理引擎支持CEP和ESP。每个事件有一个类型，一个发生时间，它也许还有 持续时间。时间点（零持续时间） 和基于时间间隔的事件都是被支持的。事件也可以像其他事实一样包含其他数据name和type属性。所有的事件都是事实但是并不是所有的事实都是事 件。一个时间的状态不应该被改变。不过，给没有赋值的值赋值是合法的。事件有一个明确的生命周期窗，当生命周期窗结束后可能有透明的垃圾回收机制（比如， 我们只对最近24小时内交易感兴趣）。规则能够处理事件之间的时间关系。复杂事件处理(COMPLEX EVENT PROCESSING)入门1Posted 七月 25, 2010Comments(2) 一个新产品需要重点考虑业务风险控制。关于风险控制系统整体的技术方案可以参考支付系统风控系统建设思考。此方案尽管能够满足业务需求，但对于海量交易数据分析、风险事件的实时处理、大量的风险规则处理上，在实时性、性能、架构的可扩展性上都不是很理想，有必要重新从架构上考虑一下实现方案。 一般而言，风险控制系统标准的软件架构如下：1、风控系统实现的几种方案 1)、数据库方案：将风险规则、交易数据等都采用关系数据库存放。正如支付系统风控系统建设思考所提到的方案，交易库和风险库一般分别部署在不同的服务器上，在事件触发上可以采用数据库触发器、消息队列事件等方案。此种方案技术实现相对简单，但在进行海量交易数据查询以及大量风险规则处理时候，数据库系统查询性能及扩展性成为一个较大的瓶颈。很难满足风险事件实时分析的要求。 2)、内存数据库方案：由于对海量交易数据的查询、分析极其消耗数据库资源，可以采用内存数据库方案来替代关系数据库，保证风险事件实时处理的性能。 但目前开源的内存数据中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大规模的业务场合应用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase价格太高。 3)、分布式缓存方案：采用Memcached等NOSQL的分布式缓存来缓存交易数据、风险规则等，但由于NOSQL解决方案并不擅长数据间的关系逻辑处理，需要在程序中大量维护业务处理逻辑，远不如关系数据库或内存数据库方案方便。 以上方案，都可以通过规则引擎（例如drools）来完成风险规则的管理和维护，避免了风险规则维护的繁琐及规则间复杂关系处理。2、Complex Event Proces