Flink主要有两种基础类型的状态：operator state。

Flink主要有两种基础类型的状态：keyed state 和operator state。
Operator State
对于Operator State(或者non-keyed state)，每个operator state绑定到一个并行operator实例上。在Flink中，Kafka Connector是一个使用Operator State的很好的例子。每个并行Kafka消费者实例维护一个主题分区和偏移的map作为它的Operator State。
当并行度被修改时，Operator State接口支持在并行operator实例上重新分配状态。进行这种重新分配可以有不同的方案。
Raw and Managed State
Keyed State 和 Operator State 有两种形式: managed和raw。
Managed State表示数据结构由Flink runtime控制，例如内部哈希表或者RocksDB。例如，“ValueState”，“ListState”等等。Flink的runtime层会编码State并将其写入checkpoint中。
Raw State是操作算子保存在它的数据结构中的state。当进行checkpoint时，它只写入字节序列到checkpoint中。Flink并不知道状态的数据结构，并且只能看到raw字节。
所有的数据流函数都可以使用managed state，但是raw state接口只可以在操作算子的实现类中使用。推荐使用managed state(而不是raw state)，因为使用managed state，当并行度变化时，Flink可以自动的重新分布状态，也可以做更好的内存管理。
注意 如果你的managed state需要自定义序列化逻辑，请参见managed state的自定义序列化以确保未来的兼容性。Flink默认的序列化不需要特殊处理。

managed non-keyed state
可以通过实现CheckpointedFunction或者ListCheckpointed接口，来使用managed non-keyed状态。

1.CheckpointedFunction
CheckpointedFunction接口通过不同的重新分配方案提供对non-keyed状态的访问。它需要实现两种方法:
void snapshotState(FunctionSnapshotContext context) throws Exception;

void initializeState(FunctionInitializationContext context) throws Exception;
每当必须执行checkpoint时，都会调用snapshotState()。对应的initializeState()在每次初始化用户定义的函数时调用，可以是在函数第一次初始化时调用，也可以是在函数实际从较早的checkpoint恢复时调用。因此，initializeState()不仅是初始化不同类型状态的地方，也是状态恢复逻辑实现地方。

目前，支持List样式的管理操作状态。状态是一个可序列化对象的列表，彼此独立，因此在重新扫描时能够进行重新分区。换句话说，这些对象是可以重新分区no-keyed状态的最佳粒度。根据状态访问方法的不同，定义了以下重分区方案:

Even-split redistribution：每个操作算子返回一个状态元素列表。逻辑上串联起所有的列表就是状态元素完整列表。在恢复/重新分区时，该列表会均分成算子实例个数个子列表。每个操作算子实例获取一个子列表，该子列表可以是空的，也可以包含一个或多个元素。例如，如果并行度为1，则操作算子的检查点状态包含元素element1和element2。当并行度增加到2时，element1可能会出现在算子实例0中，而element2会出现在算子实例1中。
Union redistribution： 每个操作算子返回一个状态元素列表。整个状态在逻辑上是串联起所有列表。在恢复/重新分发时，每个操作算子都获得状态元素的完整列表。
下面是一个有状态的SinkFunction，在讲数据元素写入外部存储之前使用CheckpointedFunction来缓存元素。主要是用来验证event-split充分布list状态。

下面的例子是一个有状态的SinkFunction，该sink会在数据发送到外部存储之前缓存数据元素。该例子是机遇均分重分布来实现的：
public class BufferingSink
implements SinkFunction<Tuple2<String, Integer>>,
CheckpointedFunction {

private final int threshold;private transient ListState<Tuple2<String, Integer>> checkpointedState;private List<Tuple2<String, Integer>> bufferedElements;public BufferingSink(int threshold) {this.threshold = threshold;this.bufferedElements = new ArrayList<>();
}@Override
public void invoke(Tuple2<String, Integer> value) throws Exception {bufferedElements.add(value);if (bufferedElements.size() == threshold) {for (Tuple2<String, Integer> element: bufferedElements) {// send it to the sink}bufferedElements.clear();}
}@Override
public void snapshotState(FunctionSnapshotContext context) throws Exception {checkpointedState.clear();for (Tuple2<String, Integer> element : bufferedElements) {checkpointedState.add(element);}
}@Override
public void initializeState(FunctionInitializationContext context) throws Exception {ListStateDescriptor<Tuple2<String, Integer>> descriptor =new ListStateDescriptor<>("buffered-elements",TypeInformation.of(new TypeHint<Tuple2<String, Integer>>() {}));checkpointedState = context.getOperatorStateStore().getListState(descriptor);if (context.isRestored()) {for (Tuple2<String, Integer> element : checkpointedState.get()) {bufferedElements.add(element);}}
}

}
initializeState方法以FunctionInitializationContext作为参数。用于初始化non-keyed状态“containers”。这是ListState类型的容器，其中non-keyed状态对象将在checkpoint上存储。
留意状态是如何初始化的，类似于keyed状态，使用一个StateDescriptor，其中包含状态名和关于状态持有的值的类型的信息:

ListStateDescriptor<Tuple2<String, Integer>> descriptor =
new ListStateDescriptor<>(
“buffered-elements”,
TypeInformation.of(new TypeHint<Tuple2<Long, Long>>() {}));

checkpointedState = context.getOperatorStateStore().getListState(descriptor);

状态访问方法的命名约定包含其重分区模式及其状态结构。例如，要在还原时使用具有union重分区方案的list state，使用getUnionListState(descriptor)访问状态。如果方法名不包含重分区模式，例如getListState(descriptor)，它仅仅意味着将使用均分重分区模式（Even-split redistribution）。
在初始化container之后，我们使用上下文的isrestore()方法检查失败后是否正在恢复。如果是true，即正在恢复，则执行恢复逻辑。
如修改后的BufferingSink代码所示，状态初始化期间恢复的数据保存在一个ListState变量中，以备将来在snapshotState()中使用。在那里，ListState将清除前一个检查点包含的所有对象，然后被我们想要检查的新选项填满。
另外，keyed状态也可以在initializeState()方法中初始化。可以使用FunctionInitializationContext来完成。
2.ListCheckpointed
ListCheckpointed接口是CheckpointedFunction的一个有限制的变体，它只支持列表样式的状态，在恢复时使用均分重分区方案。它还需要实现两种方法:
List snapshotState(long checkpointId, long timestamp) throws Exception;

void restoreState(List state) throws Exception;
在snapshotState()上，操作应该向检查点返回一个对象列表，而restoreState()必须在恢复时处理这个列表。如果状态不可重分区，则始终可以在snapshotState()中返回Collections.singletonList(MY_STATE)。

有状态的源函数(Stateful Source Functions)
与其他操作符相比，有状态源需要更多的关注。为了更新状态和输出集合的原子性(用于故障/恢复上的精确一次语义)，用户需要从源上下文获取一个锁。

public static class CounterSource
extends RichParallelSourceFunction
implements ListCheckpointed {

/**  current offset for exactly once semantics */
private Long offset;/** flag for job cancellation */
private volatile boolean isRunning = true;@Override
public void run(SourceContext<Long> ctx) {final Object lock = ctx.getCheckpointLock();while (isRunning) {// output and state update are atomicsynchronized (lock) {ctx.collect(offset);offset += 1;}}
}@Override
public void cancel() {isRunning = false;
}@Override
public List<Long> snapshotState(long checkpointId, long checkpointTimestamp) {return Collections.singletonList(offset);
}@Override
public void restoreState(List<Long> state) {for (Long s : state)offset = s;
}

}
当Flink完全确认检查点时，一些操作可能需要这些信息来与外部世界进行通信。在本例中，请参见org.apache.flink.runtime.state.CheckpointListener接口。