数据流中的恰好一次处理 (exactly-once processing) 确保数据管道中的每个事件都只被精确地处理一次，即使在执行过程中发生故障或重试。这种保证避免了重复处理和数据丢失，这些是在分布式系统中常见的挑战，因为节点或网络可能会发生故障。实现恰好一次处理需要数据源、处理引擎和接收器之间的协调，以跟踪进度、管理状态和原子地处理重试。例如，像 Apache Flink 或 Kafka Streams 这样的框架通过结合检查点、事务日志和幂等操作来实现这一点，以保持管道所有阶段的一致性。
为了实现恰好一次处理，系统通常依赖于三个关键机制。首先，**幂等操作** 确保多次重新应用相同的操作（例如，更新数据库）与执行一次具有相同的效果。其次，**事务写入** 将更新分组为原子单元：如果发生故障，事务中的所有更改都会回滚，从而避免部分更新。例如，Kafka 的事务生产者允许原子地写入多个主题，确保所有消息都被提交或都不被提交。第三，**检查点** 定期将处理管道的状态（例如，偏移量或中间结果）保存到持久存储。如果发生故障，系统从上一个检查点重新启动，而不是重新处理所有数据。例如，Apache Flink 使用分布式快照来协调跨节点的检查点，确保所有组件都同意管道的进度。
然而，恰好一次处理也引入了一些权衡。检查点、事务协调和幂等性检查的开销会影响延迟和吞吐量。例如，Flink 中频繁的检查点会增加延迟，而 Kafka 的事务生产者需要额外的往返于 Broker。开发人员还必须设计接收器（例如，数据库或 API）来支持幂等写入或事务，这可能并不总是可行的。一个实际的例子是金融应用程序，必须避免重复付款——恰好一次处理在这里至关重要。相比之下，指标聚合管道可能会为了简单起见而容忍至少一次语义。最终，选择取决于用例的一致性要求以及系统处理增加的复杂性的能力。