深入解析Flink两阶段提交Sink机制

TwoPhaseCommitSinkFunction 分析

TwoPhaseCommitSinkFunction 是 Apache Flink 中一个抽象基类，用于实现精确一次（exactly-once）语义的 Sink 函数。它基于两阶段提交算法（Two-Phase Commit Algorithm），通过实现 CheckpointedFunction 和 CheckpointListener 接口来保证数据的一致性。

让我们先看类的定义：

@Internal
public abstract class TwoPhaseCommitSinkFunction<IN, TXN, CONTEXT> extends RichSinkFunction<IN>
        implements CheckpointedFunction, CheckpointListener {
    // ...
}

这个类具有三个泛型参数：

• IN: 输入数据类型
• TXN: 事务句柄类型，用于存储处理事务所需的所有信息
• CONTEXT: 上下文类型，在给定的 TwoPhaseCommitSinkFunction 实例的所有调用中共享

从注释可以看出，这是所有希望实现精确一次语义的 SinkFunction 的推荐基类。它通过在 CheckpointedFunction 和 CheckpointListener 基础上实现两阶段提交算法来实现这一目标。

继承了CheckpointedFunction接口，在预提交阶段，能够通过检查点将待写出的数据可靠地存储起来；

继承了CheckpointListener接口，在提交阶段，能够接收JobMaster的确认通知，触发提交外部事务。

需要注意的是，该类已被标记为 @Deprecated，建议使用新的 org.apache.flink.api.connector.sink2.Sink 接口替代。

为什么 (Why)

在流处理系统中，确保数据处理的精确一次语义是非常重要的。传统的 Sink 函数可能因为各种故障导致数据重复或丢失。TwoPhaseCommitSinkFunction 的设计目的是解决这些问题，提供以下保障：

1. 精确一次语义: 确保每条记录只被处理一次，即使在发生故障时也是如此。
2. 容错能力: 在发生故障后能够恢复未完成的事务。
3. 一致性保证: 通过两阶段提交协议确保分布式系统中的一致性。

两阶段提交是分布式系统中保证原子性的经典算法，包含两个阶段：

1. 准备阶段（Preparation Phase）: 协调者询问所有参与者是否可以提交事务，参与者执行事务但不提交。
2. 提交阶段（Commit Phase）: 如果所有参与者都准备好，则协调者发送提交请求，否则发送回滚请求。

在 Flink 中，Checkpoint 机制扮演了协调者的角色。

怎么做 (How)

TwoPhaseCommitSinkFunction 通过以下几个核心组件和方法实现两阶段提交：

核心数据结构

1. pendingCommitTransactions: 存储待提交的事务，使用 LinkedHashMap<Long, TransactionHolder<TXN>> 结构，其中 key 是检查点ID。
2. currentTransactionHolder: 当前正在进行的事务。
3. State: 封装了 pendingTransaction、pendingCommitTransactions 和 context 的状态对象，用于快照和恢复。

关键方法实现

1. beginTransaction(): 抽象方法，由子类实现创建新事务的逻辑。
2. invoke(): 在当前事务中处理输入数据。
3. preCommit(): 预提交事务，将数据刷新到存储系统但不真正提交。
4. commit(): 提交预提交的事务。
5. abort(): 中止事务。
6. recoverAndCommit()/recoverAndAbort(): 故障恢复时提交或中止事务。

工作流程

1. 初始化阶段:

   • 在 initializeState() 方法中，如果从检查点恢复，则会恢复之前的事务状态。
   • 调用 beginTransactionInternal() 开始一个新的事务。

2. 数据处理阶段:

   • 每条记录通过 invoke() 方法在当前事务中处理。
   • 处理逻辑由子类实现的抽象方法 invoke(TXN transaction, IN value, Context context) 完成。

3. 检查点阶段:

   • 在 snapshotState() 方法中，对当前事务进行预提交 (preCommit)。
   • 将当前事务与检查点ID关联并保存到 pendingCommitTransactions。
   • 开始一个新的事务用于后续数据处理。

4. 检查点完成阶段:

   • 在 notifyCheckpointComplete() 方法中，提交所有与已完成检查点相关联的事务。
   • 这确保了只有在检查点成功完成后才提交数据。

5. 故障恢复:

   • 在 initializeState() 中，如果有恢复状态，则调用 recoverAndCommit() 提交之前未完成的事务。
   • 对于未预提交的事务，调用 recoverAndAbort() 中止它们。

事务管理和超时处理

该类还提供了事务超时相关的配置选项：

• setTransactionTimeout(): 设置事务超时时间
• ignoreFailuresAfterTransactionTimeout(): 超时后忽略提交失败
• enableTransactionTimeoutWarnings(): 启用事务超时警告

这些功能帮助用户更好地监控和管理长时间运行的事务。

状态序列化

为了支持故障恢复，该类实现了自定义的状态序列化器 StateSerializer，能够正确序列化和反序列化事务状态，包括：

• 当前事务
• 待提交的事务列表
• 用户上下文

通过以上机制，TwoPhaseCommitSinkFunction 实现了一个完整的两阶段提交框架，使得开发者只需要关注具体事务操作的实现，而不需要关心复杂的容错和一致性保证逻辑。

snapshotState 方法分析

@Override
public void snapshotState(FunctionSnapshotContext context) throws Exception

这个方法实现了 CheckpointedFunction 接口中的 snapshotState 方法。主要目的是在检查点触发时执行两阶段提交协议的第一阶段——预提交（pre-commit）。它会：

1. 预提交当前事务
2. 将当前事务保存到待提交事务列表中
3. 开始一个新的事务
4. 更新状态快照

1. 获取检查点ID并记录日志

long checkpointId = context.getCheckpointId();
LOG.debug(
        "{} - checkpoint {} triggered, flushing transaction '{}'",
        name(),
        context.getCheckpointId(),
        currentTransactionHolder);

这部分代码获取当前检查点的ID，并记录一条调试日志，表明检查点已触发，并显示当前正在处理的事务。

2. 预提交当前事务

if (currentTransactionHolder != null) {
    preCommit(currentTransactionHolder.handle);
    pendingCommitTransactions.put(checkpointId, currentTransactionHolder);
    LOG.debug("{} - stored pending transactions {}", name(), pendingCommitTransactions);
}

如果存在当前事务（currentTransactionHolder 不为null），则：

• 调用 preCommit 方法对当前事务进行预提交。这是两阶段提交的第一步，通常意味着事务已经准备好提交，但还没有最终提交。
• 将当前事务添加到 pendingCommitTransactions 映射中，键是检查点ID。这允许系统在后续的 notifyCheckpointComplete 方法中根据检查点ID找到对应的事务并进行提交。

3. 开始新的事务

// no need to start new transactions after sink function is closed (no more input data)
if (!finished) {
    currentTransactionHolder = beginTransactionInternal();
} else {
    currentTransactionHolder = null;
}
LOG.debug("{} - started new transaction '{}'", name(), currentTransactionHolder);

这部分代码决定是否需要开始一个新的事务：

• 如果 finished 标志为false（表示sink函数仍在处理数据，还有输入数据），则调用 beginTransactionInternal() 方法开始一个新事务。
• 否则，将 currentTransactionHolder 设置为null。
• 记录一条调试日志，显示新开始的事务。

4. 更新状态快照

state.update(
        Collections.singletonList(
                new State<>(
                        this.currentTransactionHolder,
                        new ArrayList<>(pendingCommitTransactions.values()),
                        userContext)));

这部分代码更新算子的状态快照，将其持久化存储。状态包括：

• 当前事务 (currentTransactionHolder)
• 所有待提交的事务列表 (pendingCommitTransactions.values())
• 用户上下文 (userContext)

这个状态会在故障恢复时使用，确保事务的一致性和精确一次语义。

设计考量

1. 两阶段提交协议: 该方法实现了两阶段提交协议的第一阶段，即预提交。这确保了在发生故障时能够正确地恢复事务状态。
2. 事务管理: 通过维护 pendingCommitTransactions 映射，系统可以跟踪所有待提交的事务，并在检查点完成时正确提交它们。
3. 状态持久化: 通过更新状态快照，确保在发生故障时可以从最近的检查点恢复，保证精确一次语义。
4. 资源管理: 在任务完成后（finished为true）不再创建新事务，避免不必要的资源消耗。

beginTransactionInternal 函数详解

beginTransactionInternal不仅负责创建新的事务，还通过 TransactionHolder 封装了事务及其元数据（主要是创建时间），为后续的事务管理和超时处理提供了基础。这种设计体现了良好的封装性和职责分离原则，使得整个两阶段提交机制更加健壮和易于维护。

private TransactionHolder<TXN> beginTransactionInternal() throws Exception {
    return new TransactionHolder<>(beginTransaction(), clock.millis());
}

具体实现分析

1. 封装事务对象： beginTransactionInternal 是一个私有方法，专门用于创建新的事务，并将其包装在 TransactionHolder 对象中。

2. 调用抽象方法： 该方法首先调用抽象方法 beginTransaction()，这是由具体的子类实现的，负责实际创建一个新的事务。例如，在 Kafka 中，这会创建一个新的 Kafka 事务。

3. 记录时间戳： 同时，该方法通过 clock.millis() 获取当前系统时间，并作为第二个参数传递给 TransactionHolder 的构造函数。

4. 创建 TransactionHolder： 最终返回一个 TransactionHolder 对象，它包含：

   • 实际的事务对象（来自 beginTransaction() 调用）
   • 事务创建的时间戳

TransactionHolder 类的作用

从我们查看的代码可以看出，TransactionHolder 是一个包装类，具有以下特点：

1. 存储事务句柄：

   private final TXN handle;
   

2. 记录创建时间：

   private final long transactionStartTime;
   

   这个时间戳对于跟踪事务的持续时间至关重要，特别是在处理事务超时的情况下。

3. 提供辅助方法：

   • elapsedTime(Clock clock)：计算事务已运行的时间
   • equals() 和 hashCode()：支持对象比较和哈希表操作
   • toString()：便于调试和日志输出

在整体架构中的作用

1. 统一入口： 正如方法注释所指出的："This method must be the only place to call beginTransaction() to ensure that the TransactionHolder is created at the same time."

   这确保了所有事务的创建都通过同一个入口点，从而保证每个事务都被正确地包装在 TransactionHolder 中，并记录了创建时间。

2. 在 snapshotState 中的应用： 在 snapshotState 方法中，当需要开始一个新事务时，会调用 beginTransactionInternal()。

3. 在 initializeState 中的应用： 在 initializeState 方法中，当需要初始化一个新的事务时，也会调用 beginTransactionInternal()。

设计

1. 时间追踪： 通过记录事务创建时间，Flink 可以监控事务的持续时间，这对于检测长时间运行的事务和处理超时情况非常重要。

2. 一致性保证： 确保每次创建事务时都会记录时间戳，避免了手动记录可能带来的遗漏或不一致问题。

3. 简化子类实现： 子类只需要关注如何创建事务本身（实现 beginTransaction() 方法），而不需要关心时间戳记录等通用逻辑。

initializeState 方法详解

 

@Override
public void initializeState(FunctionInitializationContext context) throws Exception

initializeState 方法是 CheckpointedFunction 接口的一个重要方法，在算子初始化时被调用。它负责：

• 初始化状态
• 在故障恢复时恢复之前的状态
• 处理未完成的事务

核心功能分解

获取状态存储

state = context.getOperatorStateStore().getListState(stateDescriptor);

这行代码从 Flink 的状态存储中获取一个 ListState，用于存储 TwoPhaseCommitSinkFunction 的状态。

状态恢复逻辑

boolean recoveredUserContext = false;
if (context.isRestored()) {
    LOG.info("{} - restoring state", name());
    for (State<TXN, CONTEXT> operatorState : state.get()) {
        // 恢复用户上下文
        userContext = operatorState.getContext();
        
        // 处理待提交的事务
        List<TransactionHolder<TXN>> recoveredTransactions =
                operatorState.getPendingCommitTransactions();
        List<TXN> handledTransactions = new ArrayList<>(recoveredTransactions.size() + 1);
        
        // 对每个待提交事务执行恢复提交操作
        for (TransactionHolder<TXN> recoveredTransaction : recoveredTransactions) {
            // 如果提交失败，可能导致数据丢失
            recoverAndCommitInternal(recoveredTransaction);
            handledTransactions.add(recoveredTransaction.handle);
            LOG.info("{} committed recovered transaction {}", name(), recoveredTransaction);
        }
        
        // 处理待处理但未提交的事务（需要中止）
        if (operatorState.getPendingTransaction() != null) {
            TXN transaction = operatorState.getPendingTransaction().handle;
            recoverAndAbort(transaction);
            handledTransactions.add(transaction);
            LOG.info(
                    "{} aborted recovered transaction {}",
                    name(),
                    operatorState.getPendingTransaction());
        }
        
        // 完成上下文恢复
        if (userContext.isPresent()) {
            finishRecoveringContext(handledTransactions);
            recoveredUserContext = true;
        }
    }
}

初始化用户上下文

// 如果没有恢复任何用户上下文或者从头开始初始化
if (!recoveredUserContext) {
    LOG.info("{} - no state to restore", name());
    userContext = initializeUserContext();
}

清空待提交事务并开始新事务

this.pendingCommitTransactions.clear();
currentTransactionHolder = beginTransactionInternal();
LOG.debug("{} - started new transaction '{}'", name(), currentTransactionHolder);

关键组件详解

State 是一个内部类，用于封装所有需要持久化的状态信息：

• pendingTransaction: 当前正在进行但尚未预提交的事务
• pendingCommitTransactions: 预提交但尚未完全提交的事务列表
• context: 用户上下文

TransactionHolder 包装了实际的事务对象和创建时间戳：

• handle: 实际的事务对象
• transactionStartTime: 事务开始的时间，用于超时检测

recoverAndCommitInternal 方法

这是恢复过程中提交事务的核心方法：

private void recoverAndCommitInternal(TransactionHolder<TXN> transactionHolder) {
    try {
        // 检查是否接近超时并记录警告
        logWarningIfTimeoutAlmostReached(transactionHolder);
        // 执行实际的提交操作
        recoverAndCommit(transactionHolder.handle);
    } catch (final Exception e) {
        // 处理超时事务的异常
        final long elapsedTime = clock.millis() - transactionHolder.transactionStartTime;
        if (ignoreFailuresAfterTransactionTimeout && elapsedTime > transactionTimeout) {
            LOG.error(
                    "Error while committing transaction {}. "
                            + "Transaction has been open for longer than the transaction timeout ({})."
                            + "Commit will not be attempted again. Data loss might have occurred.",
                    transactionHolder.handle,
                    transactionTimeout,
                    e);
        } else {
            throw e;
        }
    }
}

故障恢复策略

initializeState 方法实现了复杂的故障恢复策略：

1. 待提交事务处理: 对于已经预提交但尚未完全提交的事务，尝试重新提交它们
2. 待处理事务中止: 对于已经开始但尚未预提交的事务，选择中止它们以避免重复处理
3. 上下文恢复: 恢复用户自定义的上下文信息
4. 超时处理: 在恢复过程中检查事务是否超时并相应处理

设计考虑

1. 精确一次语义: 通过仔细管理事务状态确保精确一次处理语义
2. 容错性: 提供多种配置选项来处理事务超时和失败情况
3. 可扩展性: 允许用户自定义上下文和事务处理逻辑
4. 日志记录: 详细的日志记录帮助调试和监控

注意事项

1. 数据丢失风险: 注释明确指出，如果恢复提交最终失败，可能会发生数据丢失
2. 事务顺序: 事务按创建顺序恢复，这对于某些外部系统很重要
3. 超时配置: 提供了多种配置选项来处理长时间运行的事务

通过这种方式，initializeState 方法确保了在任务重启或故障恢复后，能够正确地恢复事务状态并继续处理数据，从而保证了精确一次的语义。

为什么snapshotState 和 initializeState 都会开始事务

在 Flink 的 TwoPhaseCommitSinkFunction 中，snapshotState 和 initializeState 都会调用 beginTransactionInternal() 开始新事务的原因是为了确保在任何时候都有一个活跃的事务可以处理数据。

 

在 TwoPhaseCommitSinkFunction 中，事务的生命周期是连续的：

• 在任务初始化时 (initializeState)，需要创建第一个事务来处理数据
• 在每次检查点时 (snapshotState)，当前事务会被预提交，然后需要创建一个新的事务来处理后续数据

在 initializeState 方法中开启事务是为了：

• 确保在任务启动后立即有一个活跃的事务来处理输入数据
• 处理任务重启后的状态恢复，确保恢复后能正常处理数据

@Override
public void initializeState(FunctionInitializationContext context) throws Exception {
    // ... 状态恢复逻辑 ...

    // 创建初始事务
    currentTransactionHolder = beginTransactionInternal();
    LOG.debug("{} - started new transaction '{}'", name(), currentTransactionHolder);
}

在 snapshotState 方法中开启事务是为了：

• 在当前事务被预提交后，需要一个新的事务来处理检查点之后的数据
• 维持事务的连续性，确保不会因为等待检查点完成而阻塞数据处理

@Override
public void snapshotState(FunctionSnapshotContext context) throws Exception {
    // ... 预提交当前事务 ...

    // 如果任务未完成，则创建新事务
    if (!finished) {
        currentTransactionHolder = beginTransactionInternal();
    } else {
        currentTransactionHolder = null;
    }
    LOG.debug("{} - started new transaction '{}'", name(), currentTransactionHolder);
}

这种设计有几个重要原因：

连续处理数据：Flink 是一个流处理系统，需要能够持续不断地处理数据。如果在检查点期间不创建新事务，那么在检查点完成之前就没有活跃的事务来处理新到达的数据，这会导致数据处理的中断。

两阶段提交协议要求：

1. 第一阶段（预提交）：在检查点时将当前事务预提交
2. 第二阶段（提交）：在检查点完成后提交事务

在这个过程中，为了不阻塞新数据的处理，需要立即开始一个新的事务。

容错性和一致性保证

通过这种方式，即使在检查点过程中发生故障，系统也能保证：

• 已经预提交的事务可以在恢复时正确提交
• 新数据会在新的事务中处理，不会丢失

具体流程示例

让我们通过一个具体的例子来说明：

1. 任务启动 -> initializeState 调用 beginTransactionInternal() 创建第一个事务 T1
2. 数据流入 -> 使用事务 T1 处理数据
3. 检查点触发 -> snapshotState 调用：
   • 将事务 T1 预提交
   • 将 T1 放入待提交事务列表
   • 调用 beginTransactionInternal() 创建新事务 T2
4. 数据继续流入 -> 使用事务 T2 处理新数据
5. 检查点完成 -> notifyCheckpointComplete 提交事务 T1
6. 循环继续 -> 下一个检查点时重复上述过程

这种设计确保了系统的高吞吐量和数据一致性，同时实现了精确一次的语义保证。

notifyCheckpointComplete 方法详细分析

@Override
public final void notifyCheckpointComplete(long checkpointId) throws Exception

这是一个重写了 CheckpointListener 接口的方法，负责在检查点完成时提交之前预提交的事务。它是 Flink 中实现精确一次语义的关键组件之一，在两阶段提交协议的第二阶段起作用。

方法开头的注释描述了三种可能的情况：

(1) 单个事务提交

• 最常见的情况：只有一个来自最新触发并完成的检查点的事务
• 直接提交该事务即可

(2) 多个待提交事务

• 当前一个检查点被跳过时会发生这种情况
• 可能的原因：
  • 主节点无法持久化上一个检查点的元数据（存储系统临时中断），但可以持久化后续检查点
  • 其他任务在上一个检查点期间无法持久化它们的状态，但由于能够保持状态并在后续检查点成功持久化而没有触发失败
• 在这两种情况下，先前的检查点从未达到已提交状态，但当前检查点应始终预期会取代先前的检查点并涵盖自上次成功以来的所有更改。因此，需要提交所有待处理的事务

(3) 检查点通知延迟

• 多个事务正在等待，但检查点完成通知与最新的不相关
• 这是可能的，因为通知消息可能会延迟（在极端情况下直到下一个检查点触发后才到达）
• 并且可能存在并发重叠的检查点（在前一个完全完成之前启动新的检查点）

notifyCheckpointComplete 通过以下方式确保精确一次语义：

1. 处理多种复杂情况：正确处理单个事务、多个待提交事务以及检查点通知延迟等情况
2. 事务提交：安全地提交所有应该提交的事务
3. 错误处理：妥善处理提交过程中可能出现的异常
4. 超时监控：提供事务超时警告机制，帮助诊断潜在问题
5. 状态管理：维护待提交事务的状态，确保事务只被提交一次

核心实现逻辑

Iterator<Map.Entry<Long, TransactionHolder<TXN>>> pendingTransactionIterator =
        pendingCommitTransactions.entrySet().iterator();
Throwable firstError = null;

while (pendingTransactionIterator.hasNext()) {
    Map.Entry<Long, TransactionHolder<TXN>> entry = pendingTransactionIterator.next();
    Long pendingTransactionCheckpointId = entry.getKey();
    TransactionHolder<TXN> pendingTransaction = entry.getValue();
    if (pendingTransactionCheckpointId > checkpointId) {
        continue;
    }

    LOG.info(
            "{} - checkpoint {} complete, committing transaction {} from checkpoint {}",
            name(),
            checkpointId,
            pendingTransaction,
            pendingTransactionCheckpointId);

    logWarningIfTimeoutAlmostReached(pendingTransaction);
    try {
        commit(pendingTransaction.handle);
    } catch (Throwable t) {
        if (firstError == null) {
            firstError = t;
        }
    }

    LOG.debug("{} - committed checkpoint transaction {}", name(), pendingTransaction);

    pendingTransactionIterator.remove();
}

if (firstError != null) {
    throw new FlinkRuntimeException(
            "Committing one of transactions failed, logging first encountered failure",
            firstError);
}

详细步骤解析：

1. 获取待提交事务迭代器

   Iterator<Map.Entry<Long, TransactionHolder<TXN>>> pendingTransactionIterator =
           pendingCommitTransactions.entrySet().iterator();
   

   获取 pendingCommitTransactions 映射的迭代器，该映射存储了检查点 ID 和对应的事务持有者。

2. 错误处理初始化

   Throwable firstError = null;
   

   初始化一个变量来捕获第一个遇到的异常。

3. 遍历待提交事务

   while (pendingTransactionIterator.hasNext()) {
       Map.Entry<Long, TransactionHolder<TXN>> entry = pendingTransactionIterator.next();
       Long pendingTransactionCheckpointId = entry.getKey();
       TransactionHolder<TXN> pendingTransaction = entry.getValue();
       if (pendingTransactionCheckpointId > checkpointId) {
           continue;
       }
   

   遍历所有待提交的事务，如果事务关联的检查点 ID 大于当前完成的检查点 ID，则跳过该事务。

4. 日志记录

   LOG.info(
           "{} - checkpoint {} complete, committing transaction {} from checkpoint {}",
           name(),
           checkpointId,
           pendingTransaction,
           pendingTransactionCheckpointId);
   

   记录事务提交的日志信息。

5. 事务超时警告检查

   logWarningIfTimeoutAlmostReached(pendingTransaction);
   

   检查事务是否接近超时，如果是则输出警告日志。

6. 事务提交

   try {
       commit(pendingTransaction.handle);
   } catch (Throwable t) {
       if (firstError == null) {
           firstError = t;
       }
   }
   
   // ...
       /**
        * Commit a pre-committed transaction. If this method fail, Flink application will be restarted
        * and {@link TwoPhaseCommitSinkFunction#recoverAndCommit(Object)} will be called again for the
        * same transaction.
        */
       protected abstract void commit(TXN transaction);

   尝试提交事务，如果发生异常则捕获并保存第一个异常。

7. 调试日志和移除已提交事务

   LOG.debug("{} - committed checkpoint transaction {}", name(), pendingTransaction);
   pendingTransactionIterator.remove();
   

   记录调试日志并从待提交事务列表中移除已提交的事务。

8. 异常抛出

   if (firstError != null) {
       throw new FlinkRuntimeException(
               "Committing one of transactions failed, logging first encountered failure",
               firstError);
   }
   

   如果存在异常，则抛出运行时异常。

超时处理机制

在提交事务之前，会调用 logWarningIfTimeoutAlmostReached 方法检查事务是否接近超时：

private void logWarningIfTimeoutAlmostReached(TransactionHolder<TXN> transactionHolder) {
    final long elapsedTime = transactionHolder.elapsedTime(clock);
    if (transactionTimeoutWarningRatio >= 0
            && elapsedTime > transactionTimeout * transactionTimeoutWarningRatio) {
        LOG.warn(
                "Transaction {} has been open for {} ms. "
                        + "This is close to or even exceeding the transaction timeout of {} ms.",
                transactionHolder.handle,
                elapsedTime,
                transactionTimeout);
    }
}

该方法计算事务已经打开的时间，如果超过了设定的超时比例阈值，则输出警告日志。

为什么 TwoPhaseCommitSinkFunction 被认为是过时的

TwoPhaseCommitSinkFunction 是一个用于实现恰好一次（exactly-once）语义的 Sink 函数，它通过两阶段提交协议（2PC）来保证数据的一致性。虽然它在早期版本中被广泛使用，但它存在以下问题：

a. 与 Checkpoint 机制紧密耦合

TwoPhaseCommitSinkFunction 的实现依赖于 Flink 的 Checkpoint 机制，它通过 Checkpoint 的生命周期来触发事务的准备和提交阶段。这种设计使得 Sink 的实现与 Flink 的 Checkpoint 机制紧密耦合，导致以下问题：

• 扩展性差：当 Flink 的 Checkpoint 机制发生变化时，TwoPhaseCommitSinkFunction 的实现也需要相应调整。
• 难以适应新的执行模式：例如，当 Flink 引入新的执行模式（如批处理或混合执行模式）时，TwoPhaseCommitSinkFunction 的设计可能无法很好地适应。

b. 状态管理复杂

TwoPhaseCommitSinkFunction 需要手动管理事务的状态（例如，未完成的事务列表），并且需要在 Checkpoint 时将这些状态持久化。这种手动管理状态的方式容易出错，并且增加了实现的复杂性。

c. 不支持异步提交

TwoPhaseCommitSinkFunction 的提交操作是同步的，这意味着在提交事务时，Flink 任务会被阻塞，直到提交完成。这可能会影响性能，特别是在外部系统响应较慢的情况下。

d. 缺乏灵活性

TwoPhaseCommitSinkFunction 的设计较为固定，难以支持更复杂的 Sink 场景，例如：

• 支持不同的提交策略（如批量提交、异步提交等）。
• 与其他 Sink 模式（如 at-least-once、at-most-once）的集成。

org.apache.flink.api.connector.sink2.Sink 的优势

新的 org.apache.flink.api.connector.sink2.Sink 接口是 Flink 为 Sink 组件设计的新一代 API，它解决了 TwoPhaseCommitSinkFunction 的许多问题，并提供了更好的设计和灵活性。

a. 更清晰的职责分离

Sink 接口将 Sink 的职责分解为多个组件：

• SinkWriter：负责将数据写入外部系统。
• Committer：负责提交事务或确认写入操作。
• GlobalCommitter：可选组件，用于全局提交操作（例如，在分布式系统中协调多个 Committer）。

这种设计使得每个组件的职责更加清晰，便于维护和扩展。

b. 更好的异步支持

新的 Sink 接口支持异步提交操作，允许 Sink 在后台提交数据，而不会阻塞 Flink 任务的执行。这可以显著提高性能，特别是在与外部系统交互时。

c. 更灵活的状态管理

新的 Sink 接口提供了更灵活的状态管理机制，允许开发者根据需要自定义状态的持久化和恢复逻辑。这减少了手动管理状态的复杂性，并降低了出错的可能性。

d. 更好的扩展性

新的 Sink 接口设计更加模块化，支持不同的提交策略和执行模式。它可以轻松适应 Flink 的新功能和执行模式，例如批处理、流处理和混合执行模式。

e. 与 Flink 的新架构对齐

新的 Sink 接口与 Flink 的新架构（如 Stateful Functions、DataStream API 的改进等）对齐，能够更好地支持未来的功能扩展。

总结

TwoPhaseCommitSinkFunction 虽然在早期版本中是一个有效的解决方案，但它的设计存在与 Checkpoint 机制紧密耦合、状态管理复杂、缺乏异步支持等问题。相比之下，新的 org.apache.flink.api.connector.sink2.Sink 接口通过职责分离、异步支持、灵活的状态管理和更好的扩展性，提供了更现代化和高效的 Sink 实现方式。因此，Flink 社区推荐使用新的 Sink 接口来替代 TwoPhaseCommitSinkFunction。

Sink 接口

 Flink 新一代 Sink API 的核心接口，它采用了更清晰的职责分离设计。从代码中可以看出，Flink Sink API V2 主要包含以下几个核心组件：

1. Sink 接口：基础接口，用于创建 SinkWriter
2. SinkWriter 接口：负责数据写入
3. SupportsCommitter 接口：支持两阶段提交协议的 Sink 扩展接口
4. Committer 接口：负责提交数据的第二阶段
5. CommittingSinkWriter 接口：执行两阶段提交协议第一阶段的 SinkWriter
6. StatefulSinkWriter 接口：支持状态管理的 SinkWriter
7. SupportsWriterState 接口：支持 SinkWriter 状态管理的 Sink 扩展接口

在 FileSink 中，我们看到：

1. FileSink 实现了 Sink 接口，提供了 createWriter 方法创建 FileWriter
2. FileSink 还实现了 SupportsWriterState 和 SupportsCommitter 接口，支持状态恢复和两阶段提交
3. FileWriter 实现了 StatefulSinkWriter 和 CommittingSinkWriter 接口，既支持状态管理又支持两阶段提交
4. FileWriterBucket 负责具体的文件写入操作，在 prepareCommit 方法中将进行中的文件转为待提交状态
5. FileCommitter 实现了 Committer 接口，负责将待提交的文件正式提交

这种设计的优势在于：

1. 职责分离：将数据写入（SinkWriter）和数据提交（Committer）分离，使架构更清晰
2. 支持精确一次语义：通过两阶段提交协议实现精确一次语义
3. 灵活性：可以根据需要实现不同的接口组合来满足不同的需求
4. 可扩展性：易于扩展新的 Sink 实现

Sink 相关接口设计

在 Flink 中，Sink 相关接口的设计主要围绕着两阶段提交（Two-Phase Commit）机制展开。两阶段提交是一种分布式事务处理协议，用于确保在分布式系统中所有参与者都能达成一致的状态。Flink 的 Sink 接口设计支持这种机制，以确保数据的一致性和可靠性。

Sink 接口是 Flink Sink 的基础接口，定义了 Sink 的基本行为。它是一个泛型接口，泛型参数 IN 表示输入数据的类型。

public interface Sink<IN> {
    // 创建 SinkWriter 实例
    SinkWriter<IN> createWriter(InitContext context) throws IOException;
}

SinkWriter 接口负责将数据写入到外部系统。它定义了写入数据的方法，以及在检查点（Checkpoint）时如何处理数据。

public interface SinkWriter<IN> extends AutoCloseable {
    // 写入数据
    void write(IN element, Context context) throws IOException, InterruptedException;

    // 在检查点时准备提交数据
    Collection<Committable> prepareCommit() throws IOException, InterruptedException;

    // 在检查点完成后提交数据
    void commit(Collection<Committable> committables) throws IOException, InterruptedException;
}

Committer 接口负责提交数据。它定义了提交数据的方法，以及在提交失败时如何处理。

public interface Committer<CommT> extends AutoCloseable {
    // 提交数据
    void commit(Collection<CommitRequest<CommT>> committables) throws IOException, InterruptedException;
}

FileSink 类分析

FileSink 是 Flink 中用于将数据写入文件系统的 Sink 实现。它通过两阶段提交机制确保数据的一致性和可靠性。

FileSink 通过以下步骤实现两阶段提交：

1. 写入阶段：数据首先被写入到临时文件中，这些文件被称为 "in-progress" 文件。
2. 准备提交阶段：在检查点时，FileSink 将 "in-progress" 文件转换为 "pending" 文件，并生成提交请求。
3. 提交阶段：Committer 接口负责将 "pending" 文件提交为最终文件，使其对外可见。

FileSink 类的关键组件

• FileWriter：负责将数据写入到文件系统。
• FileCommitter：负责提交文件，将 "pending" 文件转换为最终文件。
• BucketAssigner：负责将数据分配到不同的桶（Bucket）中。
• RollingPolicy：负责决定何时滚动文件。

两阶段提交的具体实现

在写入阶段，FileSink 使用 FileWriter 将数据写入到 "in-progress" 文件中。FileWriter 负责管理文件的创建、写入和滚动。

在准备提交阶段，FileSink 将 "in-progress" 文件转换为 "pending" 文件，并生成提交请求。这个过程在 prepareCommit 方法中完成。

在提交阶段，FileCommitter 负责将 "pending" 文件提交为最终文件。FileCommitter 实现了 Committer 接口，负责处理提交请求。

 FileSink 使用 FileWriter 和 FileCommitter 分别负责数据的写入和提交，通过 BucketAssigner 和 RollingPolicy 管理文件的分配和滚动。这种设计使得 FileSink 能够高效地处理大量数据，并确保数据在分布式环境中的可靠性。

FileWriter

FileWriter<IN> 是 Apache Flink 中用于文件输出的一个核心组件，它是 FileSink 的具体实现中的写入器(writer)部分。从类的定义可以看出：

public class FileWriter<IN>
        implements StatefulSinkWriter<IN, FileWriterBucketState>,
                CommittingSinkWriter<IN, FileSinkCommittable>,
                SinkWriter<IN>,
                ProcessingTimeService.ProcessingTimeCallback

FileWriter<IN> 实现了多个接口：

• StatefulSinkWriter<IN, FileWriterBucketState>: 表示这是一个有状态的写入器，可以保存和恢复状态
• CommittingSinkWriter<IN, FileSinkCommittable>: 表示这是一个支持两阶段提交协议的写入器，能生成提交信息
• SinkWriter<IN>: 基础的写入器接口
• ProcessingTimeService.ProcessingTimeCallback: 处理时间回调接口，用于定时检查桶的状态

核心功能：

1. 管理多个活动的桶(bucket)，每个桶对应一个目录
2. 将数据写入到相应的桶中
3. 在检查点期间准备提交信息
4. 维护写入器的状态，支持故障恢复

为什么需要 FileWriter?

设计背景和需求：

1. 精确一次语义: Flink 需要保证在发生故障时数据不会丢失也不会重复写入
2. 分区管理: 数据通常需要按照某种规则（如时间、键值等）分桶存储
3. 批量写入优化: 为了提高性能，需要将数据批量写入文件系统
4. 状态管理: 在流处理过程中，需要能够保存和恢复写入器的状态
5. 两阶段提交: 为了保证跨系统的事务一致性，需要支持两阶段提交协议

解决的问题：

1. 数据一致性: 通过 in-progress、pending、finished 三种文件状态确保数据一致性
2. 容错恢复: 通过状态快照和恢复机制，在发生故障时能从最近的一致状态恢复
3. 性能优化: 通过批量写入和合理的文件滚动策略提高写入性能
4. 灵活分区: 支持自定义的桶分配策略，满足不同的业务需求

怎么做 

主要字段：

// 配置字段
private final Path basePath;                           // 基础路径
private final FileWriterBucketFactory<IN> bucketFactory; // 桶工厂
private final BucketAssigner<IN, String> bucketAssigner; // 桶分配器
private final BucketWriter<IN, String> bucketWriter;   // 桶写入器
private final RollingPolicy<IN, String> rollingPolicy; // 滚动策略
private final ProcessingTimeService processingTimeService; // 处理时间服务
private final long bucketCheckInterval;               // 桶检查间隔

// 运行时字段
private final Map<String, FileWriterBucket<IN>> activeBuckets; // 活跃桶映射
private final OutputFileConfig outputFileConfig;      // 输出文件配置

构造函数：

public FileWriter(
        final Path basePath,
        final SinkWriterMetricGroup metricGroup,
        final BucketAssigner<IN, String> bucketAssigner,
        final FileWriterBucketFactory<IN> bucketFactory,
        final BucketWriter<IN, String> bucketWriter,
        final RollingPolicy<IN, String> rollingPolicy,
        final OutputFileConfig outputFileConfig,
        final ProcessingTimeService processingTimeService,
        final long bucketCheckInterval)

构造函数接收所有必要的依赖项，遵循依赖注入原则。

核心方法实现

1. write 方法 - 数据写入：

@Override
public void write(IN element, Context context) throws IOException, InterruptedException {
    // 设置桶上下文的值
    bucketerContext.update(
            context.timestamp(),
            context.currentWatermark(),
            processingTimeService.getCurrentProcessingTime());

    // 获取元素应该写入的桶ID
    final String bucketId = bucketAssigner.getBucketId(element, bucketerContext);
    
    // 获取或创建对应的桶
    final FileWriterBucket<IN> bucket = getOrCreateBucketForBucketId(bucketId);
    
    // 在桶中写入元素
    bucket.write(element, processingTimeService.getCurrentProcessingTime());
    
    // 更新记录计数器
    numRecordsOutCounter.inc();
}

2. prepareCommit 方法 - 准备提交：

@Override
public Collection<FileSinkCommittable> prepareCommit() throws IOException {
    List<FileSinkCommittable> committables = new ArrayList<>();

    // 在每次准备提交前，先检查并移除不活跃的桶
    Iterator<Map.Entry<String, FileWriterBucket<IN>>> activeBucketIt =
            activeBuckets.entrySet().iterator();
    while (activeBucketIt.hasNext()) {
        Map.Entry<String, FileWriterBucket<IN>> entry = activeBucketIt.next();
        if (!entry.getValue().isActive()) {
            activeBucketIt.remove();
        } else {
            // 从每个活跃桶中收集提交信息
            committables.addAll(entry.getValue().prepareCommit(endOfInput));
        }
    }

    return committables;
}

3. snapshotState 方法 - 状态快照：

@Override
public List<FileWriterBucketState> snapshotState(long checkpointId) throws IOException {
    checkState(bucketWriter != null, "sink has not been initialized");

    List<FileWriterBucketState> state = new ArrayList<>();
    for (FileWriterBucket<IN> bucket : activeBuckets.values()) {
        // 为每个活跃桶创建状态快照
        state.add(bucket.snapshotState());
    }

    return state;
}

两阶段提交工作流程：

1. 第一阶段 - 写入和准备提交：

   • 数据通过 write() 方法写入对应的桶
   • 桶内的数据被写入 in-progress 文件
   • 在检查点时调用 prepareCommit() 方法
   • 桶将 in-progress 文件转换为 pending 文件
   • 返回 FileSinkCommittable 对象给协调器

2. 第二阶段 - 提交：

   • FileCommitter 接收 FileSinkCommittable 对象
   • 将 pending 文件移动到最终位置，标记为 finished
   • 清理不再需要的临时文件

文件状态管理：

Flink FileSink 使用三种文件状态来保证数据一致性：

1. in-progress: 当前正在写入的文件
2. pending: 已经关闭但尚未提交的文件
3. finished: 已经成功提交的文件

在故障恢复时：

• pending 文件会被提交（因为它们已经完整）
• in-progress 文件会被回滚（删除其中在检查点之后写入的数据）

桶管理机制：

FileWriter 通过 activeBuckets 映射管理多个桶，每个桶负责一个目录的数据写入：

1. 桶创建: 当第一个分配到某个桶ID的元素到达时创建新桶
2. 桶复用: 后续元素直接复用已存在的桶
3. 桶清理: 定期检查并移除不活跃的桶

时间服务集成：

FileWriter 集成了 Flink 的处理时间服务：

• 注册定时器定期检查桶状态
• 支持基于时间的文件滚动策略
• 确保即使在没有新数据到达时也能正确处理文件

总结

FileWriter<IN> 是 Flink FileSink 实现中的核心组件，它通过以下方式实现了高效、可靠、精确一次的文件输出：

1. 模块化设计: 通过 Bucket、BucketWriter、BucketAssigner 等组件实现关注点分离
2. 状态管理: 实现有状态的写入器，支持故障恢复
3. 两阶段提交: 通过 prepareCommit 和 commit 两个阶段保证数据一致性
4. 灵活配置: 支持自定义桶分配策略、滚动策略、文件命名等
5. 性能优化: 批量写入、合理的文件管理策略

这种设计使得 Flink 能够在保证数据一致性和精确一次语义的同时，提供高性能的文件输出能力。