事实组的不同伪时钟

Question

我是drools/Fusion（7. x）的新手，不知道如何解决这个要求。假设我的事件对象为Event{long： time戳， id： string}，其中id标识物理资产（如拖拉机），时间戳表示事件相对于资产触发的时间。在我的场景中，这些事件不会“实时”到达我的系统，这意味着它们可能会延迟几秒钟、几分钟甚至几天。我的规则系统需要监控多个资产。鉴于此，当评估规则时，时钟需要相对于被监控的资产，它不能是跨资产的时钟。我知道伪时钟，有没有办法为每个资产分配伪时钟？

我的假设是，时钟必须始终向前，否则时间函数将无法正常工作。以以下场景为例：资产1的事实A在1:00到达，它被插入内存并触发规则。然后事实B在2:00到达同一资产1。它也会被插入并触发规则。现在，事实Z在1:30到达资产2（离时钟还有30分钟）。我假设我不应该简单地将时钟向后推进并进行评估，而且我想将时钟设置回2:00，因为这是我收到的“最新”数据。现在假设我正在监视数千个资产，所有资产都在不同的时间发送数据。。。

我能想到的解决这个问题的最好方法是为每个资产保留一个时钟，然后在评估每个资产数据时保存引擎状态。单个基思会有不同的时钟吗，还是在容器级别？

示例规则：当同一资产的事实1在事实2之后到达时。

Answer 1

您处理问题的方式不正确。无论您使用的是实时时钟还是伪时钟，您都在使用时钟。你不能说“事实1使用时钟A，事实2使用时钟B。”

相反，您应该利用事件的元数据标记，特别是时间戳标记。此标记向Drools指出，事件中的特定字段实际上是事件的时间戳，而不是事实进入工作内存的实际时间。

例如：

import com.example.SampleEvent

declare SampleEvent
  @role( event )
  // this field is actually in the object, it's not the time the fact was inserted
  @timestamp( createdDateTime ) 
end

我不知道您的规则实际上在做什么，这里我可以预见的主要问题是，如果您的规则依赖于时态操作符或定义过期（@expires），它们将无法工作，您需要重新设计它们。特别是对于过期事件：一旦事件过期，它就会从工作记忆中删除；当您的带外事件出现时，任何以前过期的事件都已消失，无法处理。

当然，无论您使用的是时间戳还是原始的“不同的psuedo时钟”计划，这种担忧都是真实的。无论哪种方式，您都必须管理这样一个事实，即事件不能永远存在于工作内存中——您最终将耗尽资源，系统将崩溃。事件必须在某个时候被逐出，所以您需要在模型和规则中围绕这一点进行设计。