时间戳

首页 > 解决方案 > StreamTask.getCheckpointLock 弃用和自定义 Flink 源

apache-flink - StreamTask.getCheckpointLock 弃用和自定义 Flink 源

问题描述

在为 Flink 编写自定义检查点源时，必须确保下游的发射元素、检查点和水印以同步的方式发射。这是通过获取StreamContext.getCheckpointLock

Flink 1.10 引入了对 StreamTask.getCheckpointLock 的弃用，现在推荐使用MailboxExecutor需要这种同步的 for 操作。

我有一个自定义源实现，它分为多个阶段。一个SourceFunction[T] 用于读取文件位置，一个OneInputStreamOperator用于下载和向下游发送这些元素。到目前为止，我曾经StreamSourceContexts.getSourceContext收到 SourceContextused to emit 元素，如下所示：

ctx = StreamSourceContexts.getSourceContext(
      getOperatorConfig.getTimeCharacteristic,
      getProcessingTimeService,
      getContainingTask.getCheckpointLock,
      getContainingTask.getStreamStatusMaintainer,
      output,
      getRuntimeContext.getExecutionConfig.getAutoWatermarkInterval,
      -1
)

并且在整个代码中都使用此上下文来发出元素和水印：

ctx.getCheckpointLock.synchronized(ctx.collect(item))
ctx.getCheckpointLock.synchronized(ctx.emitWatermark(watermark))

使用检查点锁仍然是向下游发出元素的首选方式吗？还是现在建议我们MailboxExecutor改用并在邮箱执行线程中制作收集和水印？

标签： apache-flink

解决方案

源上下文中的检查点锁不被弃用，因为目前没有办法在没有锁的情况下实现源。正是因为这个原因，这些源已经被称为遗留源：它们产生自己的线程并且需要锁来发出数据（基于推送）。

目前对源 ( FLIP-27 ) 进行了较大的返工，它将提供基于拉取的界面。该接口是从主任务线程调用的，因此不再需要同步。如果需要完成一些异步工作，那么MailboxExecutor就是要走的路。

仅供参考，新运营商应该（而必须）只使用MailboxExecutor而不是检查点锁。

推荐阅读