drools fusion（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 = wKnowledgeBaseConfiguration(); 
config.setOption( EventProcessingOption.CLOUD ); 
等同系统属性配置： 
drools.eventProcessingMode = cloud 

2.流模式(Stream Mode) 

当处理事件流的时候需要选择流处理模式。 
在流模式下： 
(1) 插入到引擎里的事件必须是时间顺序的。 
(2) 引擎强制性的和使用的会话时钟session clock同步。 

配置流模式： 
KnowledgeBaseConfiguration config = wKnowledgeBaseConfiguration(); 
config.setOption( EventProcessingOption.STREAM ); 
等同配置系统属性： 
drools.eventProcessingMode = stream 

使用流(STREAM)模式，引擎有时间流和"现在"的概念(通过读取Session Clock的时间戳)， 
提供了以下3种支持： 
(1) 滑动窗的支持 
(2) 自动的时间生命周期管理 
(3) 使用消极模式(Negative Patterns)自动的规则延迟 

3.会话时钟(Session Clock)在流模式(Stream mode)中的作用 

setoption在云模式下，会话时钟只有一个作用，就是给插入到working momery 的事件赋予时间戳的值(如果规则没有定义时间戳属性) 
在流模式下，会话时钟负责维护当前时间戳，基于当前的时间戳，引擎根据事件的年龄计算所有时间运算，从多种源同步流，安排未来任务等等。 

4.流模式(in Stream Mode)中的消极模式(Negative Patterns) 

消极模式在流模式和云模式意义是不同的。 
在云模式下，所有的事实和事件都是预先知道的，消极模式立即计算执行 
//a rule that activates immediately upon matching 
rule "Sound the alarm" 
when 
    $f : FireDetected( ) 
    not( SprinklerActivated( ) ) 
then 
    // sound the alarm 
end 

在流模式下，带有时间约束的消极模式可以要求引擎等待一段时间后激活规则。 

//a rule that automatically delays activation due to temporal constraints 

rule "Sound the alarm" 
when 
    $f : FireDetected( ) 
    not( SprinklerActivated( this after[0s,10s] $f ) ) 
then 
    // sound the alarm 
end 

六. 滑动窗(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 threshold" 
when 
    TemperatureThreshold( $max : max ) 
    Number( doubleValue > $max ) from accumulate( 
        SensorReading( $temp : temperature ) over window:time( 10m ), 
        average( $temp ) ) 
then 
    // sound the alarm 
end 

2.滑动长度窗(Sliding Length Windows) 
滑动长度窗(允许我们的规则)仅仅匹配发生在最近X个的事件。 
例如，如果只关心最近10个IBM股票的行情，模式(pattern)可以这样写： 
StockTick( company == "IBM" ) over window:length( 10 ) 
更复杂的例子： 
如果最近100次从传感器读来的温度高于最大的临界值，发出警报。 
rule "Sound the alarm in case temperature rises above threshold" 
when 
    TemperatureThreshold( $max : max ) 
    Number( doubleValue > $max ) from accumulate( 
        SensorReading( $temp : temperature ) over window:length( 100 ), 
        average( $temp ) ) 
then 
    // sound the alarm 
end 

七.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 = wKnowledgeBaseConfiguration(); 
config.setOption( MultithreadEvaluationOption.YES ); 
等同系统属性配置： 
drools.multithreadEvaluation = <true|false> 

3.多线程管理 
配置线程池: 
//setting the maximum number of threads for rule evaluation to 5 
KnowledgeBaseConfiguration config = wKnowledgeBaseConfiguration(); 
config.setOption( (5) ); 
等同系统属性配置： 
drools.maxThreads = <-> 
配置默认值是3，负数值表示在Knowledgebase中有多少分区，引擎就会产生多少线程，使用负数值是很危险的。 

八.事件的内存管理 

要点：自动的事件内存管理只有在引擎为Stream模式下才有效。 

引擎在Steam模式下的好处之一是引擎能够根据时间约束检测出不再匹配任何规则的事件，然后引擎可以没有负作用的安全地回收事件并释放其相关的资源。 
引擎有2种基本方式计算一个事件有效期： 
(1)显式，使用过期(expiration)策略 
(2)隐式，分析事件的时间约束 

1.显式的过期偏移量(有效期) 
//explicitly defining an expiration offset of 30 minutes for StockTick events 
declare StockTick 
    @expires( 30m ) 
end 
当StockTick事件持续30分钟后，如果没有规则需要该事件，引擎将自动的回收该事件。 

2.推知的过期偏移量 

//example rule with temporal constraints 
rule "correlate orders" 
when 
    $bo : BuyOrderEvent( $id : id ) 
    $ae : AckEvent( id == $id, this after[0,10s] $bo ) 
then 
    // do something 
end 

引擎需要保存BuyOrderEvent 10秒以匹配AckEvent。 
BuyOrderEvent隐式的过期偏移量是10秒，AckEvent隐式的过期偏移量是0。 

引擎会分析整个Knowledgebase，出每个事件类型的过期偏移量。当隐式过期偏移量和显式过期偏移量冲突时，引擎会选择2个值中最大的1个
Drools Fusion介绍
文章来源Michal Bali的《Drools JBoss Rules 5.0 Developer's Guide》一书中CEP的章节部分内容。笔者翻译了过来，供大家了解Drools Fusion，CEP的概念。
规则通常或多或少操作于静态数据集（事实）。然而，对于一些系统，有必要定义时间关联的事实。他们通常叫做复杂时间处理（CEP）或者是事件流处理（ESP）。Drools Fusion，从5.0版本开始，提供了滑动窗体（sliding windows）,时间运算符（temporal operators），类型声明（type declarations）于一体的支持。
CEP 和 ESP 
CEP 和 ESP 是事件驱动架构（Event Driven Architecture）处理模式(更多关于事件处理架构的信息： 
pepad/bmichelson/2006/02/eventdriven_arc.html)。这个架构的一个主要的好处就是提供了组件的松耦合。一个组件可以发布正在执行的动作事件，其他组件可以订阅/监听这些事件。发布者和订阅者不知道对方的存在。一个订阅监听事件者不关心事件的来源。相似的，产生事件的生产者也不知道任何监听这些事件者的任何事情。一些编
排层处理实际的订阅、发布之间的装配。
一个事件代表有意义状态的改变。它通常由一个事件头和事件体组成。事件头包含了名称，发生时间，持续时间等元信息。事件体描述了发生了什么。例如，如果一个银行交易被处理，事件体应该包含交易的ID，交易数量，本人帐号，转账帐号等。
CEP 处理复杂事件。一个复杂事件是简单事件的集合。比如，一系列的巨额提款激发可疑交易事件的发生。一个复杂事件的发生是由一系列简单事件的引导形成的。
ESP 是更实时(real-time)的大量事件处理。例如，根据时间计算实时平均交易量。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。