前面的章节已经讲解了Flink状态的分类和代码示例，我们来对比一下Key State 与 Operator State 区别。
Key State 与 Operator State的区别，我们先从一下5个维度来对比：
1、适用算子类型
Key State 只适用于KeyedStream算子上
Operator State 适用于所有算子
2、分配状态
Key State 每个Key一个状态
Operator State 每个算子一个状态
3、创建和访问方式
Key State 重写RichFunction，因为RichFunction支持RuntimeContext，也就能拿到上下文
Operator State 实现CheckpointedFunction等接口
4、横向扩展
Key State 状态随着Key自动在多个算子上迁移，也就是Key State内部已经支持了横向扩展
Operator State 需要支持算子扩展重新分布
5、支持的数据结构
Key State ValueState、ListState、ReducingState、AggregatingState、MapState
Operator State ListState、BroadcastState
从根本上分析二者的差异：
状态从本质上来说，是Flink算子子任务的一种本地数据，为了保证数据可恢复性，使用Checkpoint机制来将状态数据持久化输出到存储空间上。
状态相关的主要逻辑有两项：
一、将算子子任务本地内存数据在Checkpoint时snapshot写入存储；
二、初始化或重启应用时，以一定的逻辑从存储中读出并变为算子子任务的本地内存数据。
Keyed State对这两项内容做了更完善的封装，开发者可以开箱即用。对于Operator State来说，每个算子子任务管理自己的Operator State，或者说每个算子子任务上的数据流共享同一个状态，可以访问和修改该状态。
Flink的算子子任务上的数据在程序重启、横向伸缩等场景下不能保证百分百的一致性。换句话说，重启Flink应用后，某个数据流元素不一定会和上次一样，还能流入该算子子任务上。
因此，我们需要根据自己的业务场景来设计snapshot和restore的逻辑。为了实现这两个步骤，Flink提供了最为基础的CheckpointedFunction接口类。