什么是事件驱动，实时有多快？

如果考虑它，我们可以识别许多事件驱动方案。 他们中的很多人需要实时的反应。

我们所说的实时是什么意思?

实时反应可视为即时答案。 举个例子，咖啡店里的收银员询问你想喝什么。

收银员需要即时答案，或者至少是很快给出的答案。 否则，收银员可能会重新回答问题或怀疑你粗鲁。 即时的回答不仅是必需的，也是合情合理的。 答案的时间可能会略有不同，但仍然被视为“实时”。因此，问候时应该立即回应，但在回答收银员的问题之前，稍微考虑一下您的订单也无妨。

如果将该方案转换为软件系统，你关心的就是计时：响应时间、完成时间、访问时间、启动时间等。 用户或访问的应用程序定义这些时间安排。

应始终注意系统中发生的情况。 因此，请确保不要忘记那些显而易见的事情，如日志记录、监控和记录你的时间。

总之，我们同意实时意味着瞬间的超高速。 具体速度则由给定方案指定。

事件驱动的应用程序

如果思考单击 (Click) 事件，会得到一些启发。 事件驱动的应用程序使用 即发即弃 原则。 事件会被发送或触发到下一个系统，下一个系统可以是其他服务、事件中心、流或类似 Kafka 的消息代理。 我们不必等待系统中下一个组件的响应。 松散耦合 是以最终一致性为代价实现的，这需要在另一个层面得到处理。

要发现事件驱动应用程序的本质，可以通过客户 Alex 购买咖啡和卡布奇诺的示例来了解其主要体系结构模式。

事件通知

事件通知是对具体发生事件的通知。 每个事件均被视为是一个独立事件。 一个名为 Alex 的客户购买咖啡和卡布奇诺的示例可能如下所示：

1. 事件： 亚历克斯买咖啡。

2. 事件： 亚历克斯买了一个卡布奇诺。

一位咖啡师必须仔细听取所有细节，以便完整了解亚历克斯的订单。 但两位咖啡师也可以独立准备和供应饮料。

事件传递状态转移

使用事件携带状态传输时，所有所需的信息都存储在单个事件中。 如果某个事件丢失或服务未能侦听所有事件，该模式会很有帮助。 对于我们的示例，事件如下所示：

1. 事件： 亚历克斯买咖啡。

2.事件：除咖啡外，Alex 还购买了卡布奇诺。

安排一位咖啡师只侦听第二个事件就已足够。 如果有两位咖啡师，第二位就需要协同第一位。 订单可以一起处理，但这一过程可能比完全分开处理花费更多时间。

事件溯源

在事件溯源模式下，事件存储是重点。 如你所看到的，事件与第一个示例中相同。 但是，当咖啡师收到一个事件，然后思考所有相应的事件，以获取 Alex 已下达的所有订单的当前状态时，咖啡师在此概念中扮演的功能就很重要了。

获得第二个订单后，咖啡师就会知道，Alex 的订单包含咖啡（回忆第一个订单）和卡布奇诺（客人刚下的订单）。 与第二位咖啡师并行工作并不容易。

当我们添加一个收银员来接收订单和供应饮料时，咖啡师可以独立工作来准备饮料。 他们不需要知道客户的任何信息。 收银员就是所谓的“事件存储”，在该场景中负责保存事件。 事件溯源增加了另一层复杂性，但它也增加了分离。

1. 事件： 亚历克斯买咖啡。

收银员：（第一个）订单（针对 Alex）：咖啡

2. 事件： 亚历克斯买了一个卡布奇诺。

收银员：（第二个）订单（针对 Alex）：卡布奇诺

遥测数据是实时事件

还可以考虑其他示例。 想象一下运行冷藏系统的情境，例如，针对食品或药品制造商。 你需要持续控制系统中的温度和其他相关数据。 了解遥测数据并自动控制遥测数据对于成功至关重要。 每隔两秒测量一次遥测数据，然后将其发送到控制系统，数据在其中被分析、处理和管理。这是一个事件驱动的系统。 此外，必须实时处理数据，因为必须快速做出反应，以避免业务产生悲惨后果。