应坚持Drools的知识会话

Question

我工作的一个学区，我们计划使用Drools的实现以下类型的地区组成学校的学生人数规则：

• 如果学生有3个在一年的缺勤期间，他们的出勤率指标进入WARN状态。
• 如果学生在一年内有6次缺课，则他们的出勤指标将进入CRITICAL状态。
• 如果学生在一年内有3个主要行为事件，他们的行为度量将转为WARN状态。
• 如果学生在一年内有2次轻微和2次重大行为事件，他们的行为指标将转为CRITICAL状态。
• ......这些只是我头顶的例子，但还有更多类似性质的规则。

所有这些规则都可以用Drools专家简单地表达。另外，学生的规则处理不需要是同步的。我有几个关于实现这个最好方法的问题。

1. 从一个角度来看，这可以被视为一个事件流的监控系统。这让我想到创建一个有状态的会话，每个新事件都将插入到该会话中。然而，这些事件在9个月内发生，并且相对罕见。另外，我们可以为每个学校建立一个会话，或者为每个学生创建一个会话

   • 会在内存中保持一个会话很长时间会成为问题吗？
   • 如果服务器发生故障，我们是否需要从头开始重建会话状态，或者建议您定期拍摄快照并恢复自快照时间以来发生的事实。

2. 另一种选择是在为该学生处理事件后为每个学生保留一个会话。当下一个事件进入时，我们将从存储中检索他们的会话并插入新的事实。这样我们就不需要检索引擎每次运行的所有事实来获得学生的状态。会支持这样的配置吗？有没有这样做的缺点？

3. 第三种方法是通过检索规则需要运行的所有其他事实来响应学生的新事实，创建新的KnowledgeSession并运行规则。

任何意见什么可能是最好的方法将不胜感激。

戴夫

Answer 1

我会去解决方案2号：每个学生一个会话。鉴于您不会与会话过多交互，我会将其保留在数据库中，并且只在需要时才恢复：新的缺席/事件到达，该学生的会话从数据库恢复，事实插入时，将执行规则并检索结果状态。

我在这种情况下看到的主要缺点是创建关于多个学生的规则并不简单，您必须将您的事实提供给多个会话。例如，如果您想要在单个课程中拥有超过10名具有CRITICAL状态的学生，请提醒。在这种情况下，每个类的会话就足够了。所以，正如你所看到的，你必须决定什么对你更好。但不管你选择的“单位”（学校，班级，学生），我仍然会向你推荐我前面提到的执行流程。

Drools已经支持使用JPA的数据库持久性。您可以在此处获得有关此功能的更多信息：http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/#d0e3961

基本思路是，不要使用kbase.newStatefulKnowledgeSession()创建ksessions，而是使用名为JPAKnowledgeService的帮助程序类。这个类将返回一个StatefulKnowledgeSession的包装器，它将在每个方法调用后保持其状态。在本课程中，您将找到2种重要的方法：newStatefulKnowledgeSession()，创建新的ksession并从loadStatefulKnowledgeSession()中检索数据库中的现有会话。

希望它有帮助，

Answer 2

懒惰我会去第三种方法。我将把所有事件存储在一个数据库中，然后我将按照每天，每周，每月（如果需要）批量处理所有学生。这将允许您创建一个包含多个学生，课程等的规则的会话。 如果您没有3 +百万名学生，那么您会很好，并且它将会是一个高性能的应用程序。

Answer 3

感谢您的建议和意见。我倾向于＃2的一对夫妇的原因：

• 我觉得收集了所有的事实为给定的学生从头开始重新运行它们每一个进来将是一个重量级的过程事件我宁愿避免。
• 用例我将模型作为一个运行时间非常长的监视过程，让我相信（在阅读Fusion的用例之后），将事件插入持久的KnowledgeSession是一种可行的方法。
• 我不认为问题空间的范围（即学生vs教室，学校或整个地区）是一个问题。如果我们需要教室指标，那么我们只会为类也消耗相关事件（测试，缺席等）的新规则库

一个警告是，如果规则改变，我们需要重新评估所有受影响的学生反对新的规则库，这意味着收集所有事实并从学年开始。这应该不会发生多少，但如果它变得更频繁，那么我可能会转向第三种方法。

再次感谢您的帮助。

Answer 4

有第四个选项使维护更简单。为所有学生建立一个针对整个学区的单一有状态知识课程。在每个事件被成功处理后，坚持会话以防JVM失败时需要重建工作内存。您将需要更大的RAM和堆空间分配，但在今天的时间内RAM很便宜。 （我们使用32 GB RAM并分配16 GB XM和Xmx）如果您有24x7服务器，最有可能的是，您的JVM永远不会关闭。