指定量程限制

项目
12/15/2008

在 Notification Services 中，生成器拥有自己的时钟，该时钟将运行时间划分为多个间隔。其中的每个时间间隔称为一个“量程”**。可以在定义应用程序时配置间隔长度。

由于规则处理可能滞后于系统时钟，因此可以定义一个生成器量程限制。此量程限制可以确定生成器的量程时钟运行滞后系统时钟多长时间后，Notification Services 才能跳过对某些规则的处理。

生成器的量程时钟

应用程序首次启动时，生成器的量程时钟与系统时钟同步。如果生成器量程间隔为五分钟，则生成器每隔五分钟激发一次规则，并处理应在过去的五分钟里处理的所有事件和预定订阅。

如果停止或禁用了实例、应用程序或生成器，或者如果在给定的量程内激发所有规则所用的时间比量程持续时间长，则生成器的量程时钟将滞后于实时时钟。

如果生成器量程时钟滞后，则 Notification Services 对事件历史记录规则和订阅规则的激发时间也滞后。Notification Services 将尽可能快地激发规则和处理数据，但要赶上实时时钟，可能需要一点时间，这取决于生成器的量程时钟滞后的时间。

生成器量程限制

对于事件历史记录规则和订阅规则，可以限制允许生成器的量程时钟滞后的程度。例如，可以指定应用程序只能对事件历史记录滞后四个量程，对订阅规则滞后两个量程。如果应用程序的滞后程度超过了这些限制，则将开始跳过规则激发，直到处于限制范围之内。在这种情况下，当您重新启动生成器时，Notification Services 将跳过四个量程以外的所有量程的事件历史记录规则，以及两个量程以外的所有量程的订阅规则。

生成器跳过事件历史记录规则时，将不处理在跳过的量程中到达的事件批次。生成器跳过订阅规则时，应用程序将不依据在跳过的量程期间到达的事件生成通知，并且不依据应在跳过的量程中发生的预定订阅生成通知。

演示的量程限制

在以下演示中，生成器被重新启动，并滞后于实时时钟八个量程。历史记录量程限制设置为 4，订阅规则量程限制设置为 2。生成器启动时，它只处理最后四个事件历史记录规则，以及最后两个订阅规则。

量程限制效果

示例事件和订阅时间线

生成器处理在量程 5 至量程 8（最后的四个量程）中到达的事件批次 (E9 – E12) 的事件历史记录规则。

生成器还处理应在量程 7 和量程 8（最后两个量程）中处理的所有订阅的订阅规则。对于应在量程 7 之前处理的任何订阅，将跳过订阅规则并且不生成通知。

确定量程限制值

确定生成器量程限制值时，请在处理旧数据的值和及时通知的需求之间进行平衡。如果必须拥有更多的及时通知，请设置一个低限制（如 1）。如果必须处理所有事件批和订阅，请将限制设置为 0。

如果要根据时间设置限制，请将所需的时间除以生成器量程持续时间。如果希望应用程序滞后于实时时钟的时间不超过 60 分钟，量程持续时间为 5 分钟，则 60 除以 5 得到的量程限制值为 12。

值 0 表示没有量程限制。Notification Services 将尝试处理所有量程。

默认量程限制为 1440 个量程。因此，如果量程持续时间为 1 分钟，则默认量程限制为 1 天。

设置事件历史记录规则的量程限制

如果通过 XML 定义应用程序，请使用 ChronicleQuantumLimit Element (ADF) 来设置事件历史记录规则的量程限制。
如果以编程方式定义应用程序，请使用 ChronicleQuantumLimit 属性 (NMO) 来设置事件历史记录规则的量程限制。

设置订阅规则的量程限制

如果通过 XML 定义应用程序，请使用 SubscriptionQuantumLimit Element (ADF) 来设置订阅规则的量程限制。
如果以编程方式定义应用程序，请使用 SubscriptionQuantumLimit 属性 (NMO) 来设置订阅规则的量程限制。

请参阅

通过