Flink1.4 Fault Tolerance源码解析

于 2018-06-24 16:06:23 发布
阅读量259 收藏
点赞数
分类专栏： Flink解析 文章标签： Flink、Fault Tolerance、源码
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/u014240769/article/details/84922587
版权
本文深入探讨Flink1.4的Fault Tolerance源码，聚焦Function和Operator对象，分析CheckpointedFunction接口及其在FlinkKafkaProducerBase中的应用，以及StreamOperator如何实现容错。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

前言：本篇关注Flink，对Fault Tolerance的源码实现进行阐述，主要介绍Api层及Flink现有实现。

本篇文章重点关注以下问题：

  • 具备Fault Tolerance能力的两种对象：Function和Operator

  • 分析两个接口，列举典型实现，并做简要分析

1. 具备Fault Tolerance能力的两种对象

  • Function
  • Operator

1.1 Function对象

       org.apache.flink.api.common.functions.Function

     所有用户自定义函数的基本接口，如已经预定义的FlatMapFunction就是基础自Function，Function并未定义任何方法，只是作为标识接口。

     所有Function对象的Fault Tolerance都是通过继承CheckpointedFunction接口实现的，换话说，容错能力是Function的可选项，这点与Operator不同

1.2 Operator对象

         org.apache.flink.streaming.api.operators.StreamOperator

        所有Operator的基本接口，如已经预定义的StreamFilter、StreamFlatMap就是StreamOperator的实现。

与Function是标识接口不同，StreamOperator内置了几个和检查点相关的接口方法，因此，在Operator中，容错能力是实现Operator的必选项，这点不难理解，因为Operator处于运行时时，诸如分区信息都是必要要做快照的。

 2. CheckpointedFunction

         org.apache.flink.streaming.api.checkpoint. CheckpointedFunction

 

 CheckpointedFunction接口是有状态转换函数的核心接口，两个接口方法：

  • initializeState：Function初始化的时候调用，一般用作初始化state数据结构。
  • snapshotState：请求state快照时被调用，方法签名中的参数FunctionSnapshotContext可以获取此Function中的所有State信息（快照），通过该上下文，可以获取该Function之前变更所产生的最终结果。

2.1 FlinkKafkaProducerBase

       org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumerBase


      方法签名：

public abstract class FlinkKafkaConsumerBase<T> extends RichParallelSourceFunction<T> implements

           CheckpointListener,

           ResultTypeQueryable<T>,

          CheckpointedFunction

      FlinkKafkaConsumerBase是Flink实现基于Kafka的Source的基类，Kafka提供基于offset并且可重复消费的机制，使其非常容易实现Fault Tolerance机制。

关键代码：

/** Consumer从各topic partitions读取的初始offsets. */
private Map<KafkaTopicPartition, Long> subscribedPartitionsToStartOffsets;

/** 保存已消费的、但是Offset未提交至Broken或Zk的数据. */
private final LinkedMap pendingOffsetsToCommit = new LinkedMap();

/**
 * 如果程序从Checkpoint启动，此变量保存此Consumer上次消费的offset</br>
 * 
 * <p>此变量主要由 {@link #initializeState(FunctionInitializationContext)} 进行赋值.
 *
 */
private transient volatile TreeMap<KafkaTopicPartition, Long> restoredState;

/** 在state backend上保存的State信息（Offset信息） . */
private transient ListState<Tuple2<KafkaTopicPartition, Long>> unionOffsetStates;

@Override
public final void initializeState(FunctionInitializationContext context) throws Exception {

	OperatorStateStore stateStore = context.getOperatorStateStore();
	
	// 兼容1.2.0版本的State，可无视
	ListState<Tuple2<KafkaTopicPartition, Long>> oldRoundRobinListState =
		stateStore.getSerializableListState(DefaultOperatorStateBackend.DEFAULT_OPERATOR_STATE_NAME);

	// 各Partition的offset信息
	this.unionOffsetStates = stateStore.getUnionListState(new ListStateDescriptor<>(
			OFFSETS_STATE_NAME,
			TypeInformation.of(new TypeHint<Tuple2<KafkaTopicPartition, Long>>() {})));

	if (context.isRestored() && !restoredFromOldState) {
		restoredState = new TreeMap<>(new KafkaTopicPartition.Comparator());

		// 兼容1.2.0版本的State，可无视
		for (Tuple2<KafkaTopicPartition, Long> kafkaOffset : oldRoundRobinListState.get()) {
			restoredFromOldState = true;
			unionOffsetStates.add(kafkaOffset);
		}
		oldRoundRobinListState.clear();

		if (restoredFromOldState && discoveryIntervalMillis != PARTITION_DISCOVERY_DISABLED) {
			throw new IllegalArgumentException(
				"Topic / partition discovery cannot be enabled if the job is restored from a savepoint from Flink 1.2.x.");
		}

		// 将待恢复的State信息保存进‘restoredState’变量中，以便程序异常时用于恢复
		for (Tuple2<KafkaTopicPartition, Long> kafkaOffset : unionOffsetStates.get()) {
			restoredState.put(kafkaOffset.f0, kafkaOffset.f1);
		}

		LOG.info("Setting restore state in the FlinkKafkaConsumer: {}", restoredState);
	} else {
		LOG.info("No restore state for FlinkKafkaConsumer.");
	}
}

@Override
public final void snapshotState(FunctionSnapshotContext context) throws Exception {
	if (!running) {
		LOG.debug("snapshotState() called on closed source");
	} else {
		// 首先清空state backend对应offset的全局存储（State信息）
		unionOffsetStates.clear();

		// KafkaServer的连接器，根据Kafka版本由子类实现
		final AbstractFetcher<?, ?> fetcher = this.kafkaFetcher;
		if (fetcher == null) {
			// 连接器还未初始化，unionOffsetStates的值从 restored offsets 或是 subscribedPartition上读取
			for (Map.Entry<KafkaTopicPartition, Long> subscribedPartition : subscribedPartitionsToStartOffsets.entrySet()) {
				unionOffsetStates.add(Tuple2.of(subscribedPartition.getKey(), subscribedPartition.getValue()));
			}

			if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
				// 如果启用快照时同步提交Offset，则在初始化时，用restoredState给pendingOffsetsToCommit赋值
				pendingOffsetsToCommit.put(context.getCheckpointId(), restoredState);
			}
		} else {
			// 通过连接器获取当前消费的Offsets
			HashMap<KafkaTopicPartition, Long> currentOffsets = fetcher.snapshotCurrentState();

			if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
				// 保存当前消费的Offset
				pendingOffsetsToCommit.put(context.getCheckpointId(), currentOffsets);
			}

			// 给state backend对应offset的全局存储（State信息）赋值
			for (Map.Entry<KafkaTopicPartition, Long> kafkaTopicPartitionLongEntry : currentOffsets.entrySet()) {
				unionOffsetStates.add(
						Tuple2.of(kafkaTopicPartitionLongEntry.getKey(), kafkaTopicPartitionLongEntry.getValue()));
			}
		}

		if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
			// pendingOffsetsToCommit的保护机制，最多存储100个元素，正也是此Map需要有序的原因
			while (pendingOffsetsToCommit.size() > MAX_NUM_PENDING_CHECKPOINTS) {
				pendingOffsetsToCommit.remove(0);
			}
		}
	}
}

快照总结：

  • initializeState方法从state backend中恢复State，并将相关信息保存入restoredState；
  • snapshotState方法将当前准备放入state backend的state信息保存至unionOffsetStates，如果应用需要在快照的同时提交Offset，则将消费的Offset信息保存至pendingOffsetsToCommit。
        FlinkKafkaConsumerBase继承了CheckpointListener接口，此接口是一个监听接口，以便当快照完成时通知Function进行一些必要处理；FlinkKafkaConsumerBase借用此接口来提交Offset，代码如下： 
@Override
public final void notifyCheckpointComplete(long checkpointId) throws Exception {
	if (!running) {
		LOG.debug("notifyCheckpointComplete() called on closed source");
		return;
	}

	final AbstractFetcher<?, ?> fetcher = this.kafkaFetcher;
	if (fetcher == null) {
		LOG.debug("notifyCheckpointComplete() called on uninitialized source");
		return;
	}

	if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
		try {
			// 在pendingOffsetsToCommit中找出checkpointId对应的offset信息
			final int posInMap = pendingOffsetsToCommit.indexOf(checkpointId);
			if (posInMap == -1) {
				LOG.warn("Received confirmation for unknown checkpoint id {}", checkpointId);
				return;
			}

			@SuppressWarnings("unchecked")
			// 取出checkpointId对应的Offset信息
			Map<KafkaTopicPartition, Long> offsets =
				(Map<KafkaTopicPartition, Long>) pendingOffsetsToCommit.remove(posInMap);

			// 将该checkpointId之前的Offset信息移除（pendingOffsetsToCommit有序的原因）
			for (int i = 0; i < posInMap; i++) {
				pendingOffsetsToCommit.remove(0);
			}

			if (offsets == null || offsets.size() == 0) {
				LOG.debug("Checkpoint state was empty.");
				return;
			}

			// 通过连接器向Broken或Zk提交Offset信息
			fetcher.commitInternalOffsetsToKafka(offsets, offsetCommitCallback);
		} catch (Exception e) {
			if (running) {
				throw e;
			}
		}
	}
}

 2.2 其他实现

   因项目接Kafka，故只研究了KafkaConsumerFunction的容错处理实现，其他诸如StatefulSequenceSource、MessageAcknowledgingSourceBase实现类似。

3. StreamOperator

   org.apache.flink.streaming.api.operators.StreamOperator

   
   StreamOperator内置了我们上面谈到的几个跟检查点相关的接口方法：

  • initializeState
  • snapshotState
  • notifyOfCompletedCheckpoint

        正因为快照相关方法都已内置在StreamOperator这个顶层接口中，所以operator中快照机制由可选项变成了必选项。

        这里需要注意的是snapshotState方法，它返回值为OperatorSnapshotResult。它是一个可以存储四种State类型的容器：

  • keyedStateManagedFuture
  • keyedStateRawFuture
  • operatorStateManagedFuture
  • operatorStateRawFuture
  • 有关四种State类型不是本节重点，可参考：https://ci.apache.org/projects/flink/flink-docs-release-1.5/dev/stream/state/state.html

       下面以Flink内置的一个Operator（StreamFlatMap）为切入点，介绍一些常用类。

  

3.1 AbstractStreamOperator

         org.apache.flink.streaming.api.operators.AbstractStreamOperator

   AbstractStreamOperator是StreamOperator的抽象类，为operator的实现提供模板，当然也为以上的三个跟快照相关的接口方法的实现提供了模板。

3.2 AbstractUdfStreamOperator

         org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator

       该抽象类继承自AbstractStreamOperator，用于进一步为operator的实现提供模板，不过从类名可以看出来，它主要是为用户定义函数(udf)的operator提供模板。

值得注意的是，方法snapshotState中，有如下代码：

 

if (userFunction instanceof CheckpointedFunction) {
	((CheckpointedFunction) userFunction).snapshotState(context);
	return true;
}
           Operator中出现了CheckpointedFunction，这是因为function只是静态的函数，它的运行还必须借助于operator，因此其状态也必须借助于operator来帮助其与Flink的运行时交互以达到最终的持久化的目的。

3.3 StreamFlatMap

StreamFlatMap代码较为简单，专注于使用FlatMap对应的Function实现业务逻辑。

 

@Override
public void processElement(StreamRecord<IN> element) throws Exception {
	collector.setTimestamp(element);
	userFunction.flatMap(element.getValue(), collector);
}

 4. Function和StreamOperator之间的关联

       观察AbstractUdfStreamOperator的构造函数：

 

public AbstractUdfStreamOperator(F userFunction) {
	this.userFunction = requireNonNull(userFunction);
	checkUdfCheckpointingPreconditions();
}

         可以发现，所有UDF的Operator都内嵌了对应的Function，这是因为Function仅仅是一个静态的函数，其真正需要发挥作用依赖于Operator，以便在Flink运行时进行交互达到持久化目的。

 小结

本篇剖析了Flink针对Function以及Operator如何做快照以及如何恢复的实现。虽然，还没有涉及到fault tolerance的最终实现机制，但是这是我们的入口。

 

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值