什么是事件驱动，“实时”有多快？
如果我们认真思考，我们可以发现许多事件驱动场景。 其中的许多场景都需要实时反应。
我们所说的“实时”是什么意思？
实时反应可以视作一个即时回应。 让我们以一家咖啡店的收银员为例，他问你要喝什么。
收银员期望立即得到答复，或者至少得到很快的答复。 否则，收银员可能会重述这个问题，或认为你没有礼貌。 即时的回答不仅是必需的，也是合情合理的。 回复时间可能略有不同，但仍被视作“实时”。所以，对他人的问候应立即回复，而对于收银员的提问，则可稍作考虑，再回答你想喝什么。
如果将这个场景转换为软件系统，那么你关注的一切都和时间有关：响应时间、完成时间、访问时间、启动时间等。 这些时间由用户或访问应用程序定义。
注意
在实时系统中，各项任务应在规定的期限内执行其功能。
你还应时刻注意系统内的运行状况。 因此，请务必关注显而易见的事项，即所设置时间的日志记录、监视和测量。
重要
确保事先指定截止期限和计时方法，并设置非阻止性监视解决方案，以用于检查。
总之，我们一致同意“实时”意味着非常快、在一瞬间发生。 具体有多快则由给定方案指定。
事件驱动的应用程序
如果思考单击 (Click) 事件，会得到一些启发。 事件驱动应用程序使用“触发并忘记”原则。 事件被发送或触发到下一个系统，下一个系统可以是其他服务、事件中心、流或类似 Kafka 的消息代理。 我们不必等待系统中的下一个响应。 实现松散耦合是为了最终的一致性，这需要在另一个层次上加以考虑。
为了发现事件驱动应用程序的本质，让我们以客户 Alex 购买咖啡和卡布奇诺为例，了解其主要体系结构模式。
事件通知
事件通知是对具体发生事件的通知。 每个事件都被视为是一个独立事件。 客户 Alex 购买咖啡和卡布奇诺的示例可能是这样的：
1.事件：Alex 购买咖啡。
2.事件：Alex 购买卡布奇诺。
如果是一位咖啡师，则必须仔细聆听所有信息，才能完全清楚 Alex 的全部需求。 但如果是两位咖啡师，也可以分别准备和提供饮品。
事件传递状态转移
在事件传递状态转移模式下，所有所需的信息都存储在单个事件中。 如果某个事件丢失或服务未能侦听所有事件，该模式会很有帮助。 对于我们的示例，事件如下所示：
1.事件：Alex 购买咖啡。
2.事件：除咖啡外，Alex 还购买了卡布奇诺。
安排一位咖啡师只侦听第二个事件就已足够。 如果有两位咖啡师，第二位就需要协同第一位。 两人可以一起提供订单内容，但此过程可能要比两人完全独立操作花更长的时间。
事件溯源
在事件溯源模式下，事件存储是重点。 可以看到，事件与第一个示例中相同。 但是，当咖啡师收到一个事件，然后思考所有相应的事件，以获取 Alex 已下达的所有订单的当前状态时，咖啡师在此概念中扮演的功能就很重要了。
获得第二个订单后，咖啡师就会知道，Alex 的订单包含咖啡（回忆第一个订单）和卡布奇诺（客人刚下的订单）。 和第二位咖啡师同时工作并非易事。
如果我们增加一位收银员来接收订单和提供饮品，我们就可以让所有咖啡师独立准备饮品。 他们不需要了解客户的任何情况。 收银员就是所谓的“事件存储”，在该场景中负责保存事件。 事件溯源增加了另一层复杂性，但可以实现彼此独立操作。
1.事件：Alex 购买咖啡。
收银员：（第一个）订单（针对 Alex）：咖啡
2.事件：Alex 购买卡布奇诺。
收银员：（第二个）订单（针对 Alex）：卡布奇诺
遥测数据是实时事件
我们也可以想到其他示例。 例如，假设场景为食品或药品生产运行制冷系统。 你需要随时控制系统中的温度和其他相关数据。 了解遥测数据并自动控制它们对于取得成功至关重要。 每两秒钟测量一次遥测数据，然后将其发送到控制系统，在控制系统中分析、加工和处理数据，这应被视为事件驱动系统。 此外，还应实时处理这些数据，因为必须尽快做出反应，才能避免给业务造成惨重损失。