一、什么是State
State是指在Flink流处理系统中的状态，默认保存在Java的堆内存中，它是指在一个流处理任务中需要保存和维护的数据。这些数据可以是任何类型的，例如计数器、累加器、列表等。Flink State是在Flink应用程序的运行过程中创建和维护的，它与Flink数据流一样，也是分布式的，可以在多个并行任务之间共享和访问。Flink中的State是非常重要的，它可以用于实现窗口操作、状态更新、容错等功能，同时也是Flink的核心特性之一。
如果没有state那么如果一个Task在处理过程中挂掉了，那么它在内存中的状态都会丢失，所有的数据都需要重新计算。
二、Keyed State和Operator State
State可以被记录，在失败的情况下数据还可以恢复。Flink中有以下两种基本类型的State，Keyed State和Operator State
1.Keyed State
Keyed State 是针对 KeyedStream 中的数据进行状态管理的机制。KeyedStream 是将数据按照指定的 key 进行分组，每个 key 对应一个组，相同 key 的数据被分配到同一个组中。Keyed State保存的是每个 key 对应的状态数据，每个 key 在对应的组中有独立的状态数据。Keyed State 可以通过 KeyedStream 的 KeyedStateStream 类型进行访问。
例如：我们在使用流数据处理中执行聚合操作。假设我们需要对特定时间段内的数据进行聚合，我们可以使用时间窗口作为键，将相应的数据存储在 Keyed State 中。在每个窗口的结束时，我们可以从 Keyed State 中检索相应的数据，并执行聚合操作。
2.Operator State
Operator State 是针对整个 Operator 中的数据进行状态管理的机制。Operator 是 Flink 中数据流处理的基本单元，每个 Operator 处理一部分数据流。Operator State保存的是整个 Operator 的状态数据，可以被 Operator 中的所有子任务访问。Operator State 可以通过 Operator 的 RuntimeContext 进行访问。
举例来说，Flink中的Kafka Connector就使用了Operator State，它会在每个Connector实例中，保存该实例消费Topic的所有(partition, offset)映射
综上，Keyed State 和 Operator State 都是用于在流处理过程中保存和管理状态的机制，但是它们的作用范围和访问方式不同。
三、State的容错
1.什么是checkPoint?
Flink中CheckPoin（检查点）t是Flink实现容错机制的核心功能，它可以在任务执行过程中定期保存任务的状态信息，以便在任务出现故障或程序异常终止时，能够使用最近一次的检查点进行恢复，从而保证数据的一致性和可靠性。Checkpoint的实现方式可以是在内存中创建一个快照，也可以将快照保存到外部存储系统中。Checkpoint的使用可以大大减少任务执行过程中数据的丢失和重复处理，提高任务的可靠性和稳定性。
2.生成快照流程：
（1）触发Checkpoint：Flink会根据一定的时间间隔或数据量阈值等条件触发Checkpoint，将当前任务的状态信息保存下来。
（2）状态快照：Flink会将当前任务的状态信息快照到内存中或保存到外部存储系统中（如HDFS）。
（3）状态异步上传：在将状态快照保存到本地后，Flink会异步将状态快照上传至外部存储系统中，以便在任务出现故障时进行恢复。
（4）状态清理：一旦Checkpoint完成，Flink会删除旧的Checkpoint快照以释放存储空间
需要注意的是，Checkpoint生成快照时会暂停任务的执行，如果数据量比较大，生成快照的时间可能会比较长，因此在设置Checkpoint时需要合理地把握时间间隔和数据量阈值等参数，以确保任务的性能和可靠性。
3.恢复快照流程：
（1）故障检测：当任务出现故障时，Flink会自动检测故障并启动故障恢复过程。
（2）选择最近的Checkpoint：Flink会选择最近的Checkpoint来恢复任务的状态，以避免数据丢失。
（3）从外部存储系统中获取状态快照：Flink会从外部存储系统中获取最近的Checkpoint快照，并将其加载到内存中。
（4）恢复状态并重放数据：一旦状态快照加载完成，Flink会恢复任务的状态并从最近的Checkpoint开始重放数据，以确保任务的输出结果与故障前保持一致。
需要注意的是，Checkpoint快照恢复可能会比较耗时，因此在设计任务时，需要考虑到任务数据的大小和复杂度等因素，以避免快照恢复过程造成的任务阻塞。同时，在设置Checkpoint时也需要考虑到性能和可靠性等因素，以确保任务的正常运行。
三.link StateBackend组件
StateBackend是Flink用于存储和管理状态的组件。它负责将流处理应用程序中的状态持久化到外部存储系统中，并在需要时重新加载。Flink提供了多种StateBackend实现，包括内存、RocksDB和FsStateBackend等。每种实现都有其特定的适用场景和优劣点。
1.MemoryStateBackend（内存）：
（1）优点：
- 速度快：内存是最快的状态存储方式，可以提供非常快的读写速度。
- 简单易用：使用内存状态后端可以避免复杂的配置和额外的依赖。
（2）缺点：
- 容易丢失数据：由于数据存储在内存中，内存状态后端不适合长时间运行的应用程序或需要保留数据的应用程序。如果应用程序崩溃或停止，所有状态都将丢失。
- 内存限制：应用程序内存是有限的，如果状态数据量很大，内存可能会不足。
2.RocksDB
（1）优点：
- 可靠性高：RocksDB是一个持久化的键值存储，可以保证数据不会丢失。
- 容量大：RocksDB可以处理数据量很大的状态，即使多达几TB的状态数据也不会出现内存问题。
- 高性能读写：RocksDB的I/O操作非常快，因此可以提供非常快的读写性能。
（2）缺点：
- 配置复杂：使用RocksDB需要进行一些复杂的配置，如启用压缩、设置缓存大小等。 -依赖性强：RocksDB需要安装和配置，这可能增加了应用程序的复杂性和依赖性。
3.FsStateBackend
（1）优点：
- 可靠性高：FsStateBackend是一个持久化的键值存储，可以保证数据不会丢失。
- 可扩展性强：FsStateBackend可以存储大量的状态数据，因为它可以将数据写入到本地文件系统或HDFS中。
- 可以快速恢复：FsStateBackend可以快速恢复状态，因为它可以从本地文件系统或HDFS中读取状态数据。
（2）缺点：
- 速度慢：相比内存状态后端和RocksDB状态后端，FsStateBackend的读写速度较慢。
- 配置复杂：使用FsStateBackend需要进行一些配置，如指定文件系统类型、路径等。
四、Restart Strategy
Flink Restart Strategy（重启策略）是指在Flink集群中发生故障时如何重新启动作业。在Flink应用程序中，可能会发生多种故障，如资源不足、节点崩溃、网络中断等，这时需要选择合适的重启策略以确保作业正常运行。Flink Restart Strategy包括以下策略：
1.NoRestartStrategy（不重启策略）
如果使用该策略，当作业失败时，Flink将不会尝试重新启动该作业。这将导致作业失败，但有时可能是必要的，例如在测试阶段或在抵达某些条件后停止作业。
2.FixedDelayRestartStrategy（固定延迟重启策略）
如果使用该策略，当作业失败时，Flink将尝试在固定延迟时间内重新启动该作业。在固定延迟时间内，如果作业再次失败，则Flink将等待下一个固定延迟时间再次尝试重新启动。这个策略可能有点简单粗暴，但在某些情况下，可以快速恢复故障。
3.FailureRateRestartStrategy（故障率重启策略）
如果使用该策略，当作业失败时，Flink将根据失败的次数和时间段确定故障率，并根据故障率决定是否重新启动作业。如果故障率过高，则Flink将停止尝试重新启动。该策略可以避免在故障高发期间反复尝试重新启动。
4.ClusterRestartStrategy（集群重启策略）
如果使用该策略，当作业失败时，Flink将重启整个Flink集群。这种策略是最暴力的，但可以确保集群处于最干净的状态，并消除可能导致故障的问题。
使用哪种重启策略取决于应用程序的需求和实际情况
