有些人可能想知道为什么有两种事件处理方式:事件流处理(ESP)和复杂事件处理(CEP)。这篇文章的最初版本是我在13年前写的。当然，ESP工具也随着时间的推移而改变。
年的一天，一位罗伯特·米切尔先生打电话给我，要我写一篇有关ESPforComputerWorld的文章。他想问几个问题作为他主要文章的补充。我们谈了一个小时。一个星期后，我的一个通讯员给我发了两个电脑世界的链接。我读到的并不是我想说的。说句公道话，米切尔先生很难在一篇字的文章和另一篇字的文章中捕捉到一小时谈话的真正内容。然而，米切尔先生的问题肯定是相关的，所以我写了一个更完整的版本，我的答案当时。
我在年又读了这篇文章，因为它是CEP网站上阅读人数最多的文章之一。在与我的同事罗伊·舒尔特(RoySchulte)一起重读这本书时，它似乎一点也不过时。ESP在年取得了预期的进展。因此，我决定更新这篇文章并重新发布。最后，再次感谢Mitchell先生激发我完成了年的文章!
CEP被设计用来解决什么问题?CEP是年至年在斯坦福大学开发的，用于分析分布式系统架构的事件驱动模拟。那是25年前的事了!事情是这样发生的。
我们首先设计了一种新的事件驱动建模和仿真语言Rapide，用于在分布式事件驱动系统中建模事件活动。分布式系统中的事件可以彼此独立地发生;它们可以在同一时间或不同时间发生;或者它们可以依次发生，一个导致另一个。因此，Rapide不仅要模拟事件发生的时间，还要模拟它们的因果关系或独立性。不仅如此，我们还需要能够为多层架构建模。因此Rapide必须捕获事件级别，并在不同级别的事件之间建立时间和成员关系。我们的第一个目标是一个新的芯片的硬件设计，包括三个层次，指令集层，寄存器传输层和硬件门级。这种层次结构在硬件设计中是标准的，并且很好地理解了如何定义不同级别的事件之间的关系。
随着新的目标体系结构的出现，我们需要对动态体系结构建模，例如空中交通控制系统，其中组件(例如飞机)可以进入或离开系统，或者组件之间的事件通信可以随时间变化。硬件系统的典型例子是SUNSparcCPU设计的版本，而软件系统的例子包括*事指挥和控制系统，如宙斯盾巡洋舰雷达控制体系结构，在民用方面，电信协议，自动化机器人制造系统，电子市场，和空中交通管制。
当您模拟一个用Rapide编写的模型时，您得到的输出并不是由事件驱动的模拟器(如Verilog或VHDL)生成的通常的按时间顺序排列的事件流。您得到了一个事件云，在三维空间中按时间和因果关系部分排序，即在每个设计级别(抽象级别)内水平排列，以及在各个级别之间垂直排列。这种部分有序的事件云称为poset(部分有序的事件集)。
此外，我们开发了一套事件处理原则和技术，用于分析posets，以了解在模拟中发生了什么。事件层次结构的构造是比较复杂的CEP分析技术之一。需要捕获的错误可能包括从低级硬件设计中的错误pin连接，到高级分布式通信进程之间的不正确同步，或者违反关键的设计约束。通过事件模式快速定义设计约束。我们将我们的原则和技术集称为复杂事件处理(CEP)。我们建立了一套基于CEP的分析工具来帮助分析posets。这包括posets的图形表示、用于在模拟输出中实时检测事件模式匹配的模式匹配器以及用于定义事件层次结构以支持高级分析的工具。
到年，发表了几篇关于Rapide语言、模拟器和CEP分析工具的论文。该系统在斯坦福大学免费提供，并已在全球范围内下载，供研究人员用于分析各种系统，包括制造业和电信行业的标准。我们已经准备好投入商业运作。但是，进入销售一种新的计算机语言的游戏总是很困难的。我已经在斯坦福Ada编译器和年Rational软件的创建中经历过了。在我看来，似乎还有另一条路。您可以应用CEP工具来分析在任何类型的事件驱动系统中创建的事件。因此，我们将分析工具从模拟器中分离出来，并开始将它们应用于当时已经成熟的面向消息的商业中间件。在任何基于事件的实时系统中，CEP工具集就是这样开发的，用于分析事件到达时(即它们“处于运动状态”时)的事件。CEP允许您将系统的设计约束定义为事件模式，并实时监视系统的输出是否违反了这些约束。此外，您可以在多层系统的每一层都这样做。
ESP与CEP有何不同?差异来自于你正在处理的问题。如果你的问题涉及到分析一系列事件，那么你可以使用ESP;另一方面，如果您需要分析事件云，那么您可以使用CEP。这有点简单，让我们更详细地讨论一下。
首先，ESP正在发展。最初，ESP的起源是不同的。在开发CEP的同时，还进行了实时事件数据分析方面的平行研究。这始于20世纪90年代中期，当时数据库社区意识到数据库太慢，无法进行实时数据分析。他们开始研究在传入数据流上运行连续查询的想法。他们使用滑动时间窗口来加快查询速度。查询的答案只对当前时间窗口中的事件有效，但是随着窗口随着时间向前滑动，答案也被更新为包含新事件并排除旧事件。这项研究被称为数据流管理(DSM)，并导致了当今的事件流处理世界。重点是实时处理大量事件中的数据。有趣的是，自20世纪90年代以来，数据库变得更快了，但与此同时，事件的数量也增加了，因此现代数据库仍然不能总是跟上当前的事件流输入。现在有超过40个商业和开源ESP产品，为实时事件流处理提供简单的分析，请参阅ESP趋势。
其次，流和云之间有一个根本的区别。事件流是按时间顺序排列的事件序列，例如股票市场订阅源。事件云是在IT系统的不同位置发生的许多事件生成活动的结果。一朵云可能包含许多溪流。流是云的一种特殊情况。但是假设您正在按照事件到达的顺序处理事件流是有好处的。它允许您设计用于处理事件中的数据的算法，这些事件使用很少的内存，因为它们不需要记住很多事件。ESP算法可以非常快。它们在到达时对流中的事件进行计算，将结果传递给下一个计算并忘记这些事件。然而,最近一些ESP系统现在有能力处理非常简单的情况下的无序事件处理的基础上,事件时间(事件发生时,根据事件的时间戳)而不是处理时间(特别是软件执行时计算,这可能是当事件到达)。这种处理无序事件的能力从年开始出现在某些ESP产品中。因此，这种现代ESP系统与最早的CEP研究有一些相似之处。
另一方面，如果您使用CEP处理云，则不能假定事件以良好的顺序到达。您需要处理事件时间，而不是处理时间。你可能会寻找一个模式实例的事件,说,a和B在一起导致C,但是当你运行搜索,实际上事件C之前到达你的观测点的或B,那么你必须记得C同时继续寻找一个a和B,导致它并将完成一个匹配的模式。事件A、B、C可以是管理协议中多个进程的操作和响应，这些进程应该同步并执行事务，但有时会失败。在找到表示已完成事务的事件之前，您可能必须记住许多事件。在这种情况下，关键是要知道哪些事件导致了哪些事件。这需要更多的内存和时间!它需要一个因果参考模型来说明事件是如何在被分析的系统中产生的。在事件到达时引用这个模型来检查A和B导致C的模式需要时间。从好的方面来说，您可以处理更丰富的问题集，不仅可以在传入事件级别处理事件数据，还可以处理业务流程管理中分层结构的流程集的正确或错误行为。
在事件驱动系统的CEP分析中使用事件层次结构是独特的。当模式匹配传入事件时，CEP分析器可能会创建新事件。这些新事件被视为比输入更高的级别。它们的目的通常是抽象表示在目标系统中发生了重要事件的输入事件模式。通过将事件模式分析应用于更高层的事件，CEP分析器可以创建事件层次结构，其中的高层包含的事件比低层输入更易于理解。例如，在分析门级芯片设计的模拟时，会创建数千个门级事件。例如，“一个来自32号门的输出信号被传送到64号门的输入端。”这个事件，以及模拟中的许多其他事件，可能被抽象到寄存器传输层，然后再抽象到指令层，最终导致创建一个更容易理解的事件，比如“添加指令完成”。这将告诉人类用户门级模拟是否按预期运行。
ESP更侧重于对事件流中的数据进行高速查询，并将数学算法应用于事件数据。最初的一些商业应用，如算法交易，与金融市场中的交易系统有关。CEP更