『大数据程序员工程师』Flink状态后端和如何管理Kafka消费偏移量，有状态流处理：Apache( 二 ) 有状态流处理：ApacheFlink状态后端

RocksDBStateBackend最适合处理大状态，长窗口或大键/值状态的ApacheFlink有状态流处理作业。
RocksDBStateBackend最适合每个高可用性设置。
RocksDBStateBackend是目前唯一可用于支持有状态流处理应用程序的增量检查点的状态后端。
使用RocksDB时，状态大小仅受可用磁盘空间量的限制，这使RocksDBStateBackend成为管理超大状态的绝佳选择。使用RocksDB时的权衡是所有状态访问和检索都需要序列化（或反序列化）才能跨越JNI边界。与上面提到的堆上后端相比，这可能会影响应用程序的吞吐量。
不同的状态后端服务于多个开发人员要求，应在开始开发应用程序之前仔细考虑和进行广泛规划后选择。这可确保选择正确的状态后端以最好地满足应用程序和业务需求。 ApacheFlink如何管理Kafka消费偏移量
在我们《FlinkFridayTip》的这一集中，我们将逐步说明ApacheFlink如何与ApacheKafka协同工作，以确保Kafka主题的记录以一次性保证进行处理。
检查点是ApacheFlink的内部机制，可以从故障中恢复。检查点是Flink应用程序状态的一致副本，包括输入的读取位置。如果发生故障， Flink将通过从检查点加载应用程序状态并从恢复的读取位置继续恢复应用程序，就像没有发生任何事情一样。您可以将检查点视为保存计算机游戏的当前状态。如果你在游戏中保存了自己的位置后发生了什么事情，你可以随时回过头再试一次。
检查点使ApacheFlink具有容错能力，并确保在发生故障时保留流应用程序的语义。应用程序可以定期触发检查点。
ApacheFlink中的Kafka消费者将Flink的检查点机制与有状态运算符集成在一起，其状态是所有Kafka分区中的读取偏移量。触发检查点时，每个分区的偏移量都存储在检查点中。 Flink的检查点机制确保所有操作员任务的存储状态是一致的，即它们基于相同的输入数据。当所有操作员任务成功存储其状态时，检查点完成。因此，当从潜在的系统故障重新启动时，系统提供一次性状态更新保证。
下面我们将介绍ApacheFlink如何在逐步指南中检查Kafka消费者抵消。在我们的示例中，数据存储在Flink的JobMaster中。值得注意的是，在POC或生产用例下，数据通常存储在外部文件存储器（如HDFS或S3）中。步骤1：
下面的示例从Kafka主题中读取两个分区，每个分区包含“A” ， “B” ， “C” ， “D” ， “E”作为消息。我们将两个分区的偏移量设置为零。

文章图片
第2步：
在第二步中， Kafka消费者开始从分区0读取消息。消息“A”在“飞行中”处理，第一个消费者的偏移量变为1 。

文章图片
第3步：
在第三步中，消息“A”到达FlinkMapTask 。两个消费者都读取他们的下一个记录（分区0的消息“B”和分区1的消息“A”）。两个分区的偏移量分别更新为2和1 。与此同时， Flink的JobMaster决定在源头触发检查点。

文章图片
第4步：
在接下来的步骤中， Kafka使用者任务已经创建了状态的快照（“offset=2,1”），现在存储在ApacheFlink的JobMaster中。源分别在来自分区0和1的消息“B”和“A”之后发出检查点屏障。检查点障碍用于对齐所有操作员任务的检查点，并保证整个检查点的一致性。消息“A”到达FlinkMapTask ，而顶级消费者继续读取其下一条记录（消息“C”）。

文章图片
第5步：
此步骤显示FlinkMapTask从两个源和检查点接收检查点障碍，其状态为JobMaster 。与此同时，消费者继续从Kafka分区阅读更多活动。