什么是事件流？

事件流是事件流处理 (ESP) 中的关键功能，支持 IT 基础架构通过在事件或变化发生时处理数据来处理大量连续的事件流。

事件流通常作为批处理的补充，用于处理大型静态数据集（或“静态数据”）。但是，事件流不是批量处理数据，而是在单个数据点出现时对其进行处理，以便架构内的软件能够实时解读和响应数据流（“动态数据”）。

高性能事件流服务可以为一系列简单和复杂的任务提供支持，从库存或产品价格发生变化时发送通知，到构建检测可疑用户活动的实时机器学习模型。即使在批处理的情况下，事件流也可通过将事件与其各自的时间戳连接起来。它还有助于识别历史趋势，从而增加数据分析的深度。

事件流以无限制、连续和实时的数据记录流为中心，称为“事件”，这是记录系统或环境中任何发生事件的基础数据结构。该术语本质上是指系统中每个数据点。因此，“流”（也称为数据流或流数据）是指这些事件的持续传递。

每个事件通常包含一个用于标识该事件或其关联实体的键值，以及一个存储事件实际数据的值。此外，它还包含一个时间戳（用于指示事件发生或记录的时间），有时还会包含关于数据源、架构版本或其他属性的元数据。

在专用流处理引擎的帮助下，事件可以在流中经历几个不同的过程。“聚合”执行数据计算，例如平均值、总和和标准差。“摄取”将流数据添加到数据库。分析处理使用流数据中的模式来预测未来事件，而丰富处理将数据点与其他数据源相结合，以提供上下文并创造意义。

事件通常与业务操作或用户导航流程相关联，通常会触发另一个操作、流程或一系列事件。以网上银行为例。

当用户点击“转账”，以将资金从一个银行账户汇款到另一个银行账户时，资金将从汇款人的账户中提取并添加到收款人的银行账户中。同时向一方（或双方）发送电子邮件或短信通知，必要时还会部署安全和欺诈预防协议。

事件是事件流的核心组件。然而，一系列其他组件使流服务能够像它们一样快速有效地处理事件。其他重要组件包括：

代理或消息代理是运行事件流平台的服务器。消息代理通过在正式消息传递协议之间转换消息，使应用程序、系统和服务能够相互通信和交换信息。这使得相互依赖的服务可以直接与彼此“对话”，即使它们是用不同语言（例如 Java 或 Python ）编写或在不同平台上实现的。它还有助于系统内流程和服务的解耦。

代理可以验证、存储、路由并将信息传递到适当的目的地。在分布式事件流系统中，代理通过在多个节点之间复制事件来确保低延迟和高可用性。代理还可以形成集群（代理集一起工作，以便更轻松地实现负载均衡和可扩展性）。

主题是事件发布到的分类或源名称，提供一种在平台内组织和筛选事件的方法。它们充当事件的“主题”，允许使用者订阅主题并仅接收相关事件。

主题可以进一步划分为分区，从而允许多个使用者同时读取一个主题，而不会破坏每个分区的顺序。

偏移量是分区内每个事件的唯一标识符，用于标记事件在序列中的位置。使用者使用偏移量来组织他们处理过的事件。例如，如果使用者断开与事件的连接并稍后重新连接，则可以从最后已知偏移量恢复处理。

鉴于数据的激增以及由此产生的数据流量激增，事件流已成为现代数据架构的重要组成部分，在需要快速决策能力的环境或希望自动执行决策职责的组织中尤其如此。

以下是事件流服务管理事件数据的方式：

1. 事件生成。当创建者（例如微服务、后端系统、IoT 生态系统或事件驱动型 API）将事件发送到事件流平台时，事件流开始。
   
   
2. 事件发布。借助客户端库，创建者将事件发布到平台内的特定主题，此时它们可供使用者（订阅该主题的应用程序和服务）使用。
   
   
3. 事件存储。平台将事件存储在预先确定的时间段内或直到事件被消耗，并由代理管理事件存储和检索过程。
   
   
4. 事件使用。使用者处理事件数据以启动其他事件。根据其目的或配置，它们可以在事件到达时立即采取行动（实时处理）、存储事件以供日后处理或编译事件以进行批处理。使用者还使用偏移量跟踪自己在数据管道中的位置，因此在发生故障或重新启动时可以从中断的位置恢复处理。
   
   
5. 事件传递。 事件代理会主动将事件分发给所有已订阅的使用者。该机制在“至少一次”语义下确保事件必达，即便出现重复投递也能保证每个事件均抵达目标终端。该机制还可支持“仅此一次”传递语义，确保每个事件被精准送达且绝无重复，或根据需求配置其他类型的语义保证。
   
   
6. 事件处理。使用并传递初始事件后，处理事件数据以执行多个下游操作，包括转换数据、聚合数据和触发复杂事件处理 (CEP) 工作流。

除标准流传输与处理功能外，事件流平台（如 Amazon Kinesis、Google Pub/Sub、Azure Event Hubs 及 IBM® Event Automation）还支持多种流处理实践，以增强功能实用性。尤其是 IBM® Event Automation，其利用开源 Apache Kafka 平台强大的数据处理能力，对事件驱动型工作流进行深度优化。

一次准确传递语义确保了流中的每个事件都能被准确处理一次，这是防止重复和丢失流事件的基本功能。大多数事件流系统都包含提供一次性语义的机制，而不管系统中其他地方是否发生故障。

当下游组件无法跟上传入事件速率时，背压可以防止流压垮系统。利用背压（一种数据流控制机制），当使用者因数据处理不堪重负或无法跟上传入事件时，他们可以向创建者发出信号，以限制或停止数据创建。

此过程允许系统通过缓冲或删除传入事件（而不是破坏整个系统）来正常处理工作负载，以便事件处理在工作负载波动时保持稳定。

事件使用者通常作为使用者组的一部分工作，以加速事件使用。平台为使用者组中的每个使用者都分配一个要处理的分区子集，从而并行使用以提高效率。如果组中的一个使用者出现故障或需要添加或删除，平台可以动态重新分配分区以保持平衡和容错能力。

事件流通常意味着以时间敏感型方式处理数据。水印支持在流处理系统中跟踪进度（使用事件时间）；它强制规定完整性阈值，指示系统何时可以将事件数据视为已完全处理。水印还可以用于确保基于时间的处理的准确性以及协调无序事件。

大多数事件流平台都提供可定制数据保留策略，允许开发人员控制事件可供使用的时长。而数据压缩是一种从主题中移除冗余或过期数据的过程，可在保留关键数据的同时，将存储占用降至最低。

值得再次指出的是，标准流架构通常会将事件创建者、事件代理和使用者分离开来，以便可以独立扩展和维护组件。

事件流是一个强大的概念，允许组织在数据生成时加以利用，从而创建响应更快、更智能的系统。随着数据驱动型决策的兴起，事件流成为现代软件架构中越来越重要的组成部分。

因此，事件流技术在各个业务领域拥有一系列用例，包括：

除了特定行业之外，事件流在与其他技术和架构协同部署时也很有用。例如，事件流有时与事件源和命令查询职责分离 (CQRS) 等模式相关联。

事件源是一种架构模式，在这种模式中，应用程序状态的变化被存储为一系列事件。与事件流一起使用时，事件源允许流媒体系统重放这些事件，以重建任何时间点的实体状态，或驱动系统的其他组件。

在 CQRS 架构模式中，系统被拆分为两种不同的模型：一种处理命令（写入），一种处理查询（读取）。事件流可用于 CQRS，将更改从写入模型实时传播到读取模型，从而实现两者之间的异步集成。

事件流也是构建事件驱动型架构的基础技术。

事件驱动型架构支持松散耦合的组件通过事件进行通信。但它不是向代理发布事件流，而是发布一个单一目的事件，其他应用程序或服务可以利用该事件依次执行操作。事件驱动型架构提供的流内处理能力（与事件流功能一起使用）使企业能够响应动态数据并根据所有当前和历史数据快速做出决策。

近年来，云提供商（包括 IBM Cloud）已开始将事件流原则作为服务提供。事件流即服务使企业可以更轻松地采用事件流，而无需管理整个底层基础架构，从而进一步拓宽事件流的用例。