[0102]完全撤销的一个优点是更高级别事件检测器的排序单元可以从它们的缓冲器中清除撤销的事件并且立即重放它们的事件流。如果事件检测器的状态改变和/或过早地生成的事件不同，则完全撤销可以尽可能高效地工作。
[0103]利用完全撤销及其生成事件的消除，事件检测器必须再次执行它们的检测工作。这消耗CPU周期。但是考虑将再次确切地生成经消除的事件的无状态检测器。显然，对于那些检测器来说撤销工作的大多数被浪费了。以上描述的完全撤销的效率强烈地取决于事件检测器的内部结构及其生成的事件。它可能引入不必要的CPU开销并且因此可能未必打破推测的可实现程度。
[0104]前述按需撤销的一个构思在于不在AEP再定位时立即发送撤销事件。替代地，如果快照状态改变和/或如果在重放期间未再次生成检测器输出事件，则可以重放事件系统并且可以仅撤销事件。更详细地，每当在重放期间发出事件时，可以验证以下两个特性是否成立:
[0105](I)快照是相等的。如果重放了事件流并且快照不同，则可以中止重放过程。因为在重放中的即将到来的过早事件引起相同的快照并且因此生成相同的事件，所以快照和先前生成的过早事件这二者保持有效。也就是说，撤销可以包括在处理新近接收到的事件时验证所存储的快照状态是否等于事件检测器的新的内部状态，并且，如果验证是肯定的，则对于更高级别事件检测器中止事件重放过程。
[0106](2)生成的事件是相等的。在重放期间再次生成的事件(即，事件类型和计数器)可以被标记为更新，并且更高级别事件检测器H的排序单元可以验证先前生成的过早事件是否等于最近生成的过早事件。如果是，则H的排序单元可能不重新插入新的事件，可能不再定位AEP，并且因此可能不触发不必要的撤销级联。换句话说，撤销过程还可以包括验证由事件检测器在处理撤销消息时生成的输出事件是否等于已经响应于最后推测地转发的事件而生成的先前生成的输出事件，并且如果验证是肯定的，则对于更高级别事件检测器中止事件重放过程。
[0107]图1lb针对上述示例示例性地例示了按需事件撤销。当新近到达事件B4被插入到缓冲器中时，可以重置所关联的事件检测器以使用快照S4= s 5并且对所重放的事件起作用。所关联的事件检测器然后将在推测地处理B4之后达到某种状态s 5’ (图1lb中未示出)。如果s5’ = s5( = s4)，即，如果所关联的事件检测器的状态不受晚到达事件B4影响，则可以中止重放和撤销，因为后续快照和过早地生成的事件将保持不变。
[0108]然而，如果所关联的事件检测器的状态受影响，则可以重放事件流并且每当生成了事件时，可以在向更高级别事件检测器H的排序单元发送更新标志之前设定它。H的排序单元然后可以在平等基础上检查经更新的事件，并且如果它是，则可以丢弃事件。
[0109]如果事件检测器是无状态的或者引起重放的事件不改变许多输出，则按需撤销可以大大减小将由完全撤销跨越事件检测器层次引入的撤销工作。
[0110]根据实施方式推测可能要求附加的系统资源来减小事件检测等待时间。剩余问题是如何设定控制推测的程度的衰减或推测因子α。推测量α的理想值导致最好的等待时间但是还避免耗尽可用的系统资源并且因此避免系统故障。一些实施方式提出了可以实现这个目标的运行时α自适应。因为当运行时测量不可用时或当发生临界情形(例如CPU负荷高于某个阈值)时它是安全的，可以将α (重新)设定为其初始值，例如Citl= 1，以便防止系统故障。例如，另一初始值还可以是Citl=0.99或α。=0.9。而且，α自适应可能仅具有本地效果，因为α仅影响单个推测排序单元226(及其关联的事件检测器210)的重放和撤销。运行其它检测器的机器上的CPU负荷可能几乎不受影响，因为上层事件检测器的推测缓冲器可能仅插入和/或撤销事件但是不启动一般而言可能取决于它自己的推测因子α的重放。
[0111]实施方式的一个构思在于将控制循环用于与拥塞控制机制类似的α自适应。所述拥塞控制设法通过在各个时间单位处使数据速率(即，保持许多要确认分组的拥塞窗口大小)加倍来使吞吐量最大化。当数据速率变得对于链路来说太高时，数据分组可能因为分组在网络中丢失而超时并且可以将数据速率(即，窗口大小)减小至I。可以保存最大窗口大小并且新的迭代开始。可以再次使窗口大小加倍直到它达到前一次迭代的窗口大小一半为止。此后，可以递增窗口大小直到再次分组丢失并且下一次迭代重新开始为止。
[0112]为了适配该构思，可以与拥塞窗口大小类似地使用推测因子α，并且CPU工作负荷作为负荷指示器。每当评估CPU负荷时，可以调整α的值。为了准确地测量CPU负荷，中间件220可以重复地(例如在各个时间区间％_之后)总计事件检测器为了事件处理需要的时间(即，tbusy)，并且与其中中间件线程中的每一个空闲的时间tidle的和有关。可以根据下式确定结果得到的忙因子b。:
[0113]bc= 1- t idle/tbusy(2)
[0114]例如，在累积空闲时间tidle= 0.1秒并且累积忙时间t busy= 0.89秒情况下，结果得到的忙因子b。= 1-(0.ls/0.89s) = 0.888。这意味着可用资源的88.8%被使用并且系统资源的大约12%仍然是可用的(假定其它过程不干扰EBS)。忙因子随着α的渐减值而增长。为了调整α，可以针对b。为下目标值(Id1)和上目标值(bu)指定区间[b1;bu]。如果忙因子b。降到Id1以下，则根据一些实施方式，CPU时间是可用的并且可以减少推测量α。如果忙因子高于bu，则CPU时间是临界的并且可以将α增加或设定为其初始值α(ι。也就是说，可以基于执行方法500的至少一个计算节点的负荷来调整推测量α，使得可以随着计算节点的渐减负荷而减少推测量α，并且反之亦然。可以再次减少推测量α直到它的值将被设定为小于(l__abest)/2为止。从那时起a可能不再迅速地减少以便慢慢地接近目标区间。也就是说，从初始值开始，可以按照第一速度减少推测量a以达到预定阈值。在已达到所述阈值之后，可以按照低于第一速度的第二速度进一步减少推测量a，直到达到了负荷的目标区间位置。
[0115]例如，在实施方式中区间[1^=0.8:1^=0.9]工作相当好。然而，忙因子b。不仅受a的选择影响。在突发情形下或当事件检测器达到其状态空间的罕见区域或慢区域时，、胃可以达到高峰。在这样的情况下，运行时a自适应可以通过将推测量a重置为其初始值a ^并且因此通过向事件检测器提供更多计算资源来适当地起反应。
[0116]对于实施方式的评估，已经分析了来自安装在德国纽伦堡的主英式足球体育场中的实时定位系统(RTLS)的位置数据流。这个RTLS以针对球的每秒2.000个采样点以及针对选手和裁判员的每秒200个采样点同时跟踪144个发送器。各个选手已装配有四个发送器，各个发送器在他的肢体中的每一个处。传感器数据包括毫米绝对位置、速率、加速度和对于任何定位的定位质量(QoL)。英式足球需要这些采样速率。在针对球的每秒2.000个采样点以及多达150km/h的速率情况下两个相继位置可以间隔开超过2cm。诸如传球、二过一或射门的英式足球事件在零点几秒内发生。低等待时间是要求的，使得事件检测器的层次能够帮助人类观察者(例如，报告者)或应该平滑地跟随感兴趣事件的相机系统立即对系统的实况输出有效(例如，参见图1)。呈现了根据实施方式对来自体育场的位置数据流应用事件处理系统和算法的结果。所使用的计算平台包括通过I Gbit全交换网络进行通信的各自装配有2.80GHz的Intel Xeon E5560四核CPU和64GB的主存储器的数个64位Linux机器。为了测试已经组织了两个业余联赛足球俱乐部之间的测试比赛。已经根据实施方式通过EBS处理了来自发送器的传入位置流。
[0117]图12描绘了例示忙因子b。与时间的关系(参见曲线1202)并且例示(l-α)与时间的关系(参见曲线1202)的图。如可以看到的，EBS可以从在可改进的负荷区域中导致忙因子(b。?0.6)的初始推测量α = I开始。将α从I减少至大约0.15将忙因子b c置于高效负荷区域中直到它在大约15秒处达到临界情形(b。- 0.9)。这个临界负荷情形导致α到α 0= I的重置，从而将忙因子b。从大约0.9减少至0.6。再次，α值被从I减少至大约0.15，从而连续地改进负荷情形直到它再次达到其高效区域为止。
[0118]为了获得基准我们已经在分布式计算集群中重放了位置流数据。甚至处理中间件的实施方式(即，用于推测处理、发布/订阅管理等的方法)占大约9，000行C++代码。在那之上已经利用被用来检测超过1，500个不同的事件类型的超过15，000行C++代码实现了超过100个事件检测器。事件检测层次有15个级别，并且重放了来自英式足球比赛的事件流的片段。测试事件流的持续时间是100秒并且包括由事件检测器生成的875，000个位置事件加上25，000个更高级别事件(不包括过早事件或反应性事件)。数据流还并入一些突发情形。经处理的数据流的平均数据速率是2.27Μ字节/秒。
[0119]推测被添加来减小缓冲中间件的等待时间。为了评估我们使用来自记录测试比赛的位置数据流并且分析来自“传球”事件检测器的输入事件延迟。这个检测器订阅6个不同的事件类型并且检测(不成功的)传球事件。我们重放位置和事件数据流两次，参见图13ο
[0120]纯动态K-slack缓冲(α = 1，附图标记1302)在对错误进行排序时更新K并且最后在流重放结尾以526ms的检测等待时间结束。它针对100秒的平均等待时间是504ms。相比之下，动态α自适应的实施方式达到小得多的检测等待时间(附图标记1304)。起初，α从Citl= I开始，并且在第一调整之后它导致大约300ms的等待时间。在重放期间它随着α自适应算法测量系统负荷而减小。当检测等待时间为64ms时α达到其最小值。在28 (以及48和78)秒之后事件流突发，并且忙因子以及因此α这二者增加，导致检测等待时间的增加。此后，α再次降低使得等待时间接近其最小值。动态推测的受测试实施方式的平均等待时间是105ms。
[0121]这些结果表明推测缓冲技术的实施方式可以在运行时强烈地减小事件的检测等待时间。贯穿整个100秒CPU负荷是相当好的，并且在临界情形下由于α自适应已经避免了系统故障。因此，能够比在纯缓冲技术情况下早得多地(即，在给定示例中小于10ms而不是超过500ms)触发相机移动和聚焦。在这个测试中平均等待时间已减小了超过400ms，其是纯缓冲将引发的等待时间的5倍以上。其它事件检测器的等待时间表现类似。
[0122]在前一个测试中我们使用了包括动态α自适应的实施方式来达到最小检测等待时间。但是一直存在α由于高系统负荷而一直增加的罕见点。为了详细地讨论α自适应的性能，我们放大来自处理事件流的前35秒的结果，参见图14。
[0123]对于测试我们已将忙因子目标区间设定为b。= [0.8 ;0.9]，并且α (线1402)从Citl=I开始。每七_=3秒α减半，并且结果忙因子b。(线1404)增加。在9秒之后b。在它位于h= 80%与bh= 90%之间的目标区间中，并且α不再被调整并停留在α =0.125处。因此，在实施方式中0.1〈α〈I。
[0124]从那时起，忙因子b。和CPU负荷这二者在80%与90%之间摇摆。在附加14秒之后(在运行时的23秒之后)b。达到0.92 (在那时的CPU负荷1406是在91% )，并且α被立即设定为其初始值α。。结果b。1404和CPU负荷1406这二者立即减少。从时间24开始α再次减半直到时间27为止。接下来，α将被设定为小于(1.0-0.125)/2 = 0.43 ( 二等分线)并且从现在起每tspantt减少了 0.05。b。1404和CPU负荷1406这二者再次增加到它们的在80 %与90 %之间的目标区间。
[0125]这些结果表明，利用α自适应算法的实施方式不仅减少α以高效地使用可用的(PU能力而且像例如在突发情形下一样，如果系统几乎过负荷则迅速地增加α (例如，将α适配为I)。因此，推测缓冲器可以避免系统故障并且能够迅速地吸收负荷突发。而且，b。和CPU负荷表现类似。因此，b。是用于通过中间件推导出CPU消耗的足够良好的指示器。
[0126]为了测量资源消耗已经重放了来自英式足球比赛的事件流片段四次。图15示出了结果得到的CPU负荷。我们记录了针对纯κ-slack缓冲(α = I)的CPU负荷1502、具有静态α = 0.5的半推测缓冲(线1504)、动态α自适应(线1506)和全推测处理(α =0，线1508)。纯缓冲1502展示了在整个100