基于Flink与KStreams的不同延迟事务数据完整性保障问询

针对Flink和KStreams分别给出实现方案：

Flink 实现要点 #

• 启用Exactly-Once语义：配置execution.checkpointing.mode: EXACTLY_ONCE，同时设置合理的检查点间隔（如execution.checkpointing.interval: 10s），确保故障后能恢复到一致状态。
• 选择持久化状态后端：采用RocksDBStateBackend，将状态存储在磁盘而非内存，避免状态丢失，同时支持大状态场景。
• 使用事务性Sink：例如KafkaSink需配置DeliveryGuarantee.EXACTLY_ONCE，通过两阶段提交（2PC）保证输出的原子性，不会出现重复或丢失数据。
• 允许无限迟到数据：设置allowedLateness(Time.days(365))（或极大值），确保所有迟到数据都能被正常处理，不被丢弃。

KStreams 实现要点 #

• 开启Exactly-Once语义：设置processing.guarantee: exactly_once_v2（Kafka 2.5+版本推荐），启用Kafka事务和状态快照机制。
• 配置RocksDB状态存储：设置state.store: rocksdb，将状态持久化到磁盘，同时避免内存溢出。
• 禁用窗口自动清理：不设置retention.ms参数，让窗口状态一直保留，直到所有迟到数据到达并完成处理。
• 依赖事务性输出：KStreams在Exactly-Once模式下默认采用事务性写入下游Kafka主题，确保每条数据仅被输出一次。

同样分Flink和KStreams给出适配方案：

Flink 实现要点 #

• 限制允许迟到时间：设置allowedLateness(Time.seconds(60))，仅处理60秒内的迟到数据；可通过sideOutputLateData将超期数据路由到侧输出流，用于后续补偿处理。
• 强制使用RocksDB状态后端：必须采用RocksDBStateBackend，将状态完全存储在磁盘，避免对象驻留内存；同时开启增量检查点（enableIncrementalCheckpointing(true)），减少状态快照的IO开销。
• 配置窗口自动清理：窗口在允许迟到时间结束后会自动清理状态，释放磁盘空间，避免状态无限累积。
• 保持Exactly-Once输出：继续使用事务性Sink（如KafkaSink的DeliveryGuarantee.EXACTLY_ONCE），确保输出的一致性。
• 合理设置重启策略：配置固定延迟重启（如restart-strategy.fixed-delay.attempts: 3），保证任务故障后能快速恢复到检查点状态。

KStreams 实现要点 #

• 设置窗口Grace时间为60秒：窗口配置示例：

  stream.windowedBy(TimeWindows.of(Duration.ofSeconds(60))
          .grace(Duration.ofSeconds(60)))
  

  Grace时间即最大允许延迟，超期后窗口关闭并清理状态。
• 强制使用RocksDB状态存储：设置state.store: rocksdb，并可通过rocksdb.config优化磁盘存储参数（如调整写缓冲大小），避免内存占用。
• 保持Exactly-Once语义：继续启用processing.guarantee: exactly_once_v2，通过Kafka事务保证输出的原子性。
• 处理超期数据：自定义Processor或Transformer捕获超期数据，将其发送到专门的错误主题，便于后续人工或自动补偿，避免数据丢失。

内容的提问来源于stack exchange，提问作者feyZ1g