Drools：替监控程序和时间敏感程序编写规则 - 软件架构设计当前位置:& &&&Drools：替监控程序和时间敏感程序编写规则Drools：替监控程序和时间敏感程序编写规则&&网友分享于：&&浏览：7次Drools：为监控程序和时间敏感程序编写规则
为监控程序和时间敏感程序编写规则 &o:p&&/o:p&
作者：Edson Tirelli &o:p&&/o:p&
在讨论完关于编写规则的抽象概念以后，我打算停一下，讨论一些真实的规则引擎用例以及怎样对这些用例编写规则。&o:p&&/o:p&
我发送了邮件到用户列表中询问大家喜欢更详细的讨论哪些用例，然后我开始收到一些反馈。在这篇文章中，我将讨论一个由Neil Goldman建议的主题，同时也是分享他对监控程序和时间敏感程序建立规则的一些想法。
这篇文章不是讨论关于事件流处理的范围，这个专题与本文有所关联，但是这个专题所涉及的面太广而不能被包括在本文中。&o:p&&/o:p&
在这个例子中我将使用Drools，但是其中的思路可以用于其它规则引擎。&o:p&&/o:p&
监控应用是用于对传感器（温度，天气，动作等等）或代理（网络单元，管理系统，管理Bean等等）传递的输入进行监控并最终采取行动。它们通常需要以接近实时的方式进行工作，被设计用来对系统状态的改变做出反应。&o:p&&/o:p&
问题是：我怎样才能架构我的应用程序才能利用到规则引擎的优点来设计监控程序呢？&o:p&&/o:p&
让我们从一个简单的例子开始讨论：假设用一个监控程序是为空调系统设置的，它必须保持温度在某一个范围之内。&o:p&&/o:p&
完成它的一个简单方法是使用规则引擎中有状态的working memory，它反射系统的状态并且规则针对状态的改变做出反应。上面例子中系统的状态是由传感器提供，因此将传感器模型作为Fact是最好的方法。规则将基于这些传感器Fact来做出决定。因此，你的规则可以是：
global org.drools.examples.acsmonitoring.AirConditioningS
rule "turn ACS on"
TemperatureSensor( celsiusGrade & 25 )
acs.turnOn();
rule "turn ACS off"
TemperatureSensor( celciusGrade & 20 )
acs.turnOff();
rule "turn ACS on"
WeatherSensor( $weather : weather )
TemperatureRange( weather == $weather, $max : maxTemperature )
TemperatureSensor( celciusGrade & $max )
acs.turnOn();
sensorReader.update( sensor );
wm.modify(sensorHandle, sensor );
wm.fireAllRules();
我们这里所说的是推论时间。如果用作推论的时间，显然需要将它看作fact模型。
引用Neil Goldman所说:&o:p&&/o:p&
" 你不要想规则条件读取操作系统的时钟作为匹配条件的一部分，因为当这些条件被评估时，你只能做很小的控制。系统时钟以一种非常高的频率进行变化，而规则引擎无法察觉这么小的如此高频率的变化。&o:p&&/o:p&
你希望你的规则可以对一个伪时钟具有敏感性，那
a) 你可以用可控制的方式更新，并且
b) 规则引擎可以被告知更新. "&o:p&&/o:p&
是的，你希望有一个可控制的时钟用来推论。一个好的想法是将时钟像之前例子中那样作为一个传感器。在前面的例子中，应用控制传感器何时和怎样被更新，以保持系统状态的连续性。同样应用可以控制规则伪时钟何时和怎样获得更新。
这一方法有一个优点，如下所列：&o:p&&/o:p&
系统持续性: 你可以保证没有额外的，未知的或预知的事件将导致fact的非连续性（所有系统管理员都知道当每日备份期结束时，及时返回一个小时前的状态是让人头痛的事情）并且应用在可控情况下处理这些情况是很棒的。&o:p&&/o:p&
&o:p& &/o:p&
自动测试: 如果你的规则是在伪时钟上推论，你可以将时钟设置需要测试的特定场景以方便编写测试，你的伪时钟可以在预定义的时间间隔上用真实时钟同步。&o:p&&/o:p&
&o:p& &/o:p&
运行模拟的能力: 假设你有一个资产管理系统（考虑最佳分类），那里有超过10000条规则来管理你的客户部门的每一个单独的资产，并且你的那些富豪级的客户过来问“倘若...?”。任何有模拟系统工作经验的人知道，一个基本的要求是有一个伪时钟。因此，如果你的10000条规则参照伪时钟编写，将这些规则将模拟特性加入应用仅仅是一个时钟设置的问题…另一方面，如果规则使用真实的时钟，你只能调整规则或更改服务器时间了…&o:p&&/o:p&
&o:p& &/o:p&
要注意的时，上面所提及的问题，没有严格的限制要求定期将你的伪时钟与系统时钟同步，只要你拥有控制，何时和怎样更新伪时钟都可以。
&o:p&&/o:p&
现在我们从代码级别来了解一下所说的情况。假设你有一个任务计划应用程序，并且你想编写的规则将在计划的时间到达后运行你的任务，或者前一个必须的任务已经完成时。你的规则应当如下：
&o:p&&/o:p&
rule "Fire based on time"
PseudoClock( $currentTime : currentTime )
$t : Task( preReq == Task.PR_TIME, executedAlready == false, scheduledTime &= currentTime )
$t.execute();
rule "Fire based on task"
$pr : Task( firedAlready == true )
$t : Task( preReq == Task.PR_TASK, executedAlready == false, preReqTask == $pr )
$t.execute();
&o:p& &/o:p&
你可能注意到在计划时间和当前时间比较时用了一个“&=”操作。这是因为通常无法保证你的规则正好在指定时间运行（除非运行在一个实时的平台），但是将在计划时间后尽早的执行。因此对时间的条件判断使用范围或一个起点来判断要比绝对值好。
&o:p&&/o:p&
监控程序也可以于无状态working memory一起工作，但是一个有状态的working memory通常对案例有更好的判断，就像上面描述那样。
时间敏感的应用
时间敏感应用程序是根据时间进行推论或反应的应用。例如：账单应用，运行模拟的应用，任务计划等等。
在这样的应用中，规则将直接或间接的依赖于时间。在这里重点注意的是不要搞混将时间作为数据还是元数据应用到规则的区别。规则引擎通常有功能特性用来将时间作为元数据处理，比如允许特性指定一个规则的生效和失效时间。&o:p&&/o:p&
你的约束条件也会被作为fact的模型（上例中的TemperatureRange），用来帮助编写更灵活的规则，避免需要对值进行硬编码，并且允许单个规则对几个不同的条件进行反应。
好了，我们已经从规则的方面来看你的问题，但是应用程序需要做什么呢？答案是：简单的保持更新传感器数据。可以通过几种办法完成，依赖于系统工作的方式，但最终通常使用查询和事件两种方式。如果你对ACS进行查询，代码如下：&o:p&&/o:p&上面是非常简单的规则，但是它们示范了这个概念。下面是利用天气传感器获得的数据建立对天气有更精密反应的规则模型：
&o:p&&/o:p&
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有展开微博窗口
微信:biaodianfu
展开分类目录
标点符（钱魏 Way）
现实生活中，规则无处不在。法律、法规和各种制度均是；对于企业级应用来说，在IT技术领域，很多地方也应用了规则，比如路由表，防火墙策略，乃至角色权限控制(RBAC)，或者Web框架中的URL匹配。不管是那种规则，都规定了一组确定的条件和此条件所产生的结果。
举一个例子：
汽车是红色
车是运动型的
驾驶员是男性
驾驶员在16-25岁之间
保险费用增加20%
从这个例子可以看出：
每条规则都是一组条件决定的一系列结果
一条规则可能与其他规则共同决定最终结果。比如例子中的规则只产生了增量，还需要与确定基数的规则共同作用才能决定最终的费率
可能存在条件互相交叉的规则，此时有必要规定规则的优先级
规则作为一种知识，其典型运用就是通过实际情况，根据给定的一组规则，得出结论。这个结论可能是某种静态的结果，也可能是需要进行的一组操作。这种规则的运用过程叫做推理。如果由程序来处理推理过程，那么这个程序就叫做推理机/推理引擎。推理引擎根据知识表示的不同采取的控制策略也是不同的，常见的类型包括基于神经网络、基于案例和基于规则的推理机。其中，基于规则的推理机易于理解、易于获取、易于管理，被广泛采用。这种推理引擎被称为“规则引擎”。
规则引擎起源于基于规则的专家系统(专家系统：源于1984年NASA的人工智能项目，现已开源，由C编写。)，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。基于规则的专家系统（RBES）包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示：
推理引擎（Inference Engine）包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。
模式匹配器决定选择执行哪个规则，何时执行规则；
议程管理模式匹配器挑选出来的规则的执行次序；
执行引擎负责执行规则和其他动作。
和人类的思维相对应，规则引擎中也存在两种推理方式：正向推理（Forward-Chaining）和反向推理（Backward-Chaining）。
正向推理也叫演绎法，由事实驱动，从 一个初始的事实出发，不断地应用规则得出结论。首先在候选队列中选择一条规则作为启用规则进行推理，记录其结论作为下一步推理时的证据。如此重复这个过程，直到再无可用规则可被选用或者求得了所要求的解为止。
反向推理也叫归纳法，由目标驱动，首先提出某个假设，然后寻找支持该假设的证据，若所需的证据都能找到，说明原假设是正确的；若无论如何都找不到所需要的证据，则说明原假设不成立，此时需要另做新的假设。
将事实与规则进行匹配的算法。常见的模式匹配算法有RETE,LFA,TREAI,LEAPS。Rete算法是目前效率最高的一个演绎法推理算法，许多规则引擎都是基于Rete算法来进行推理计算的。
推理引擎的推理步骤如下：模式匹配、冲突消解、执行引擎。
将初始数据（fact）输入 Working Memory 。
使用 Pattern Matcher 比较规则库（rule base）中的规则（rule）和数据（fact）。
如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。
解决冲突，将激活的规则按顺序放入Agenda。
使用执行引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。
规则引擎的作用：
规则外部化，即有利于规则知识的复用，也可避免改变规则时带来的代码变更问题
由规则引擎使用某种算法进行推理过程，不需要编写复杂晦涩的逻辑判断代码
开发人员的不需要过多关注逻辑判断，可以专注于逻辑处理
Rete在拉丁语中是“net”，有网络的意思。Rete算法由Carnegie Mellon University的Dr Charles L. Forgy设计发明，是一个用来实现产生式规则系统（production/inference）的高效模式匹配算法。
RETE算法可以分为两部分：规则编译（rule compilation）和运行时执行（runtime execution）。规则编译是指根据规则集生成推理网络的过程，运行时执行指将数据送入推理网络进行筛选的过程。
相关概念：
事实（Fact）：对象之间及对象属性之间的关系
规则（rule）：是由条件和结论构成的推理语句，一般表示为if…Then。一个规则的if部分称为LHS（left-hand-side），then部分称为RHS（right hand side）。
模式（module）：就是指IF语句的条件。这里IF条件可能是有几个更小的条件组成的大条件。模式就是指的不能在继续分割下去的最小的原子条件。
RETE推理网络的生成过程：从规则集{规则1，规则2……..}中拿出一条来，根据一定算法，变成RETE推理网络的节点。不断循环将所有规则都处理完，RETE推理网络就生成了。RETE网络主要分为两个部分，alpha网络和beta网络。如下图所示。
alpha网络：过滤working memory，找出符合规则中每一个模式的集合，生成alpha memory（满足该模式的集合）。有两种类型的节点，过滤type的节点和其他条件过滤的节点（我觉得这两种是依照需要设定的，也并不一定需要两种节点）。
Beta网络：有两种类型的节点Beta Memory和Join Node。前者主要存储Join完成后的集合。后者包含两个输入口，分别输入需要匹配的两个集合，由Join节点做合并工作传输给下一个节点。
在一个产生式系统中，主要流程可以分为以下步骤：
Match：找出符合LHS部分的working memory集合
Confilict resolution：选出一个条件被满足的规则
Act：执行RHS的内容
RETE算法主要改进Match的处理过程，通过构建一个网络进行匹配。
具体过程如下：
创建root节点（根节点），推理网络的入口。
拿到规则1，从规则1中取出模式1（前面说了，模式就是最小的原子条件，所以规则模式的关系是1：n）。
检查模式1中的参数类型，如果是新类型，添加一个类型节点。
检查模式1对应的Alpha节点是否存在，如果存在记录下节点的位置；如果没有，将模式1作为一个Alpha节点加入到网络中。同时根据Alpha节点建立Alpah内存表。
重复b，直到处理完所有模式。
组合Beta节点：Beta(2)左输入节点为Alpha(1)，右输入节点为Alpha(2)；Beta(i)左输入节点是Beta(i-1),右输入节点为Alpha(i)，并将两个父节点的内存表内联成为自己的内存表
重复d，直到所有Beta节点处理完毕
将动作Then部分封装成最后节点做为Beta（n）
重复2，直到所有规则处理完毕
下面是一个从网上找得例子：
C1:(年纪：研2)
C2:(性别：男)
C3:(身材：较瘦)
C4:(身高：大于175cm)
Rete算法优于传统的模式匹配算法的特点
状态保存。事实集合中的每次变化，其匹配后的状态都被保存再alpha和beta节点中。在下一次事实集合发生变化时，绝大多数的结果都不需要变化，rete算法通过保存操作过程中的状态，避免了大量的重复计算。Rete算法主要是为那些事实集合变化不大的系统设计的，当每次事实集合的变化非常剧烈时，rete的状态保存算法效果并不理想。
Drools中用到的RETE算法
编译算法描述了规则如何在Production Memory中产生一个有效的辨别网络。用一个非技术性的词来说，一个辨别网络就是用来过滤数据。方法是通过数据在网络中的传播来过滤数据。在顶端节点将会有很多匹配的数据。当我们顺着网络向下走，匹配的数据将会越来越少。在网络的最底部是终端节点（terminal nodes）。在Dr Forgy的1982年的论文中，他描述了4种基本节点：root, 1-input, 2-input and terminal。
下图是Drools中的RETE节点类型：
根节点（RootNode）是所有的对象进入网络的入口。然后，从根节点立即进入到ObjectTypeNode。ObjectTypeNode的作用是使引擎只做它需要做的事情。例如，我们有两个对象集：Account和Order。如果规则引擎需要对每个对象都进行一个周期的评估，那会浪费很多的时间。为了提高效率，引擎将只让匹配object type的对象通过到达节点。通过这种方法，如果一个应用assert一个新的account，它不会将Order对象传递到节点中。很多现代RETE实现都有专门的ObjectTypeNode。在一些情况下，ObjectTypeNode被用散列法进一步优化。
ObjectTypeNode能够传播到AlphaNodes,LeftInputAdapterNodes和BetaNodes。
1-input节点通常被称为AlphaNode。AlphaNodes被用来评估字面条件（literal conditions）。虽然，1982年的论文只提到了相等条件（指的字面上相等），很多RETE实现支持其他的操作。例如，Account.name == “Mr Trout”是一个字面条件。当一条规则对于一种object type有多条的字面条件，这些字面条件将被链接在一起。这是说，如果一个应用assert一个account对象，在它能到达下一个AlphaNode 之前，它必须先满足第一个字面条件。在Dr. Forgy的论文中，他用IntraElement conditions来表述。下面的图说明了Cheese的AlphaNode组合（name == “cheddar”，strength == “strong”）：
Drools通过散列法优化了从ObjectTypeNode到AlphaNode的传播。每次一个AlphaNode被加到一个ObjectTypeNode的时候，就以字面值（literal value）作为key，以AlphaNode作为value加入HashMap。当一个新的实例进入ObjectTypeNode的时候，不用传递到每一个AlphaNode，它可以直接从HashMap中获得正确的AlphaNode，避免了不必要的字面检查。
2-input节点通常被称为BetaNode。Drools中有两种BetaNode：JoinNode和NotNode。BetaNodes被用来对2个对象进行对比。这两个对象可以是同种类型，也可以是不同类型。
我们约定BetaNodes的2个输入称为左边（left）和右边（right）。一个BetaNode的左边输入通常是a list of objects。在Drools中，这是一个数组。右边输入是a single object。两个NotNode可以完成‘exists’检查。Drools通过将索引应用在BetaNodes上扩展了RETE算法。下图展示了一个JoinNode的使用：
注意到图中的左边输入用到了一个LeftInputAdapterNode，这个节点的作用是将一个single Object转化为一个单对象数组（single Object Tuple），传播到JoinNode节点。因为我们上面提到过左边输入通常是a list of objects。
Terminal nodes被用来表明一条规则已经匹配了它的所有条件（conditions）。 在这点，我们说这条规则有了一个完全匹配（full match）。在一些情况下，一条带有“或”条件的规则可以有超过一个的terminal node。
Drools通过节点的共享来提高规则引擎的性能。因为很多的规则可能存在部分相同的模式，节点的共享允许我们对内存中的节点数量进行压缩，以提供遍历节点的过程。下面的两个规则就共享了部分节点：
123456789101112131415
rule&&&&when&&&&&&&&Cheese( $chedddar : name&&==&&" cheddar "&&)&&&&&&&&$person : Person( favouriteCheese&&==&&$cheddar )&&&&then&&&&&&&&System.out.println( $person.getName()&&+&& "&&likes cheddar "&&);end&rule&&&&when&&&&&&&&Cheese( $chedddar : name&&==&& " cheddar "&&)&&&&&&&&$person : Person( favouriteCheese&&!=&&$cheddar )&&&&then&&&&&&&&System.out.println( $person.getName()&&+&& "&&does likes cheddar "&&);end
这里我们先不探讨这两条rule到的是什么意思，单从一个直观的感觉，这两条rule在它们的LHS中基本都是一样的，只是最后favouriteCheese，一条规则是等于$cheddar，而另一条规则是不等于$cheddar。下面是这两条规则的节点图：
从图上可以看到，编译后的RETE网络中，AlphaNode是共享的，而BetaNode不是共享的。上面说的相等和不相等就体现在BetaNode的不同。然后这两条规则有各自的Terminal Node。
RETE算法的第二个部分是运行时（runtime）。当一个应用assert一个对象，引擎将数据传递到root node。从那里，它进入ObjectTypeNode并沿着网络向下传播。当数据匹配一个节点的条件，节点就将它记录到相应的内存中。这样做的原因有以下几点：主要的原因是可以带来更快的性能。虽然记住完全或部分匹配的对象需要内存，它提供了速度和可伸缩性的特点。当一条规则的所有条件都满足，这就是完全匹配。而只有部分条件满足，就是部分匹配。（我觉得引擎在每个节点都有其对应的内存来储存满足该节点条件的对象，这就造成了如果一个对象是完全匹配，那这个对象就会在每个节点的对应内存中都存有其映象。）
参考链接：
分享到： () 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
Drools研究 drools学习
下载积分：1300
内容提示：Drools研究 drools学习 drools 决策表
文档格式：PDF|
浏览次数：68|
上传日期： 16:27:02|
文档星级：
该用户还上传了这些文档
Drools研究 drools学习
官方公共微信君，已阅读到文档的结尾了呢~~
DROOLS规则引擎模式匹配效率优化研究及实现
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
DROOLS规则引擎模式匹配效率优化研究及实现
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Drools 规则引擎_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Drools 规则引擎
上传于||文档简介
&&D​r​o​o​l​s​ ​分​为​两​个​主​要​部​分​：​构​建​(​ ​A​u​t​h​o​r​i​n​g​ ​)​和​运​行​时​(​ ​R​u​n​t​i​m​e​ ​)​。​
​
​
​
​构​建​的​过​程​涉​及​到​ ​.​d​r​l​ ​或​ ​.​x​m​l​ ​规​则​文​件​的​创​建​,​它​们​被​读​入​一​个​解​析​器​,​使​用​ ​A​N​T​L​R​  ​语​法​进​行​解​析​。​解​析​器​对​语​法​进​行​正​确​性​的​检​查​,​然​后​产​生​一​种​中​间​结​构​“​ ​d​e​s​c​r​ ​”​,​ ​d​e​s​c​r​ ​用​ ​A​S​T​ ​来​描​述​规​则​。​ ​A​S​T​ ​然​后​被​传​到​ ​P​a​c​k​a​g​e​B​u​i​l​d​e​r​ ​,​由​ ​P​a​c​k​a​g​B​u​i​l​d​e​r​ ​来​产​生​ ​P​a​c​k​a​g​e​d​ ​对​象​。​ ​P​a​c​k​a​g​e​B​u​i​l​d​e​r​ ​还​承​担​着​一​些​代​码​产​生​和​编​译​的​工​作​,​这​些​对​于​产​生​ ​P​a​c​k​a​g​e​ ​对​象
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩13页未读，继续阅读
你可能喜欢}