1.Flink源码分析——Checkpoint源码分析(二)
2.trainstep的源码checkpoint可以删吗
3.Flink mysql-cdc connector 源码解析
4.Docker Checkpoint/Restore

Flink源码分析——Checkpoint源码分析(二)

       《Flink Checkpoint源码分析》系列文章深入探讨了Flink的Checkpoint机制，本文聚焦于Task内部状态数据的源码存储过程，深入剖析状态数据的源码具体存储方式。

       Flink的源码Checkpoint核心逻辑被封装在`snapshotStrategy.snapshot()`方法中，这一过程主要由`HeapSnapshotStrategy`实现。源码在进行状态数据的源码rdma verilog源码实现快照操作时，首先对状态数据进行拷贝，源码这里采取的源码是引用拷贝而非实例拷贝，速度快且占用内存较少。源码拷贝后的源码状态数据被写入到一个临时的`CheckpointStateOutputStream`，即`$CHECKPOINT_DIR/$UID/chk-n`格式的源码目录，这个并非最终数据存储位置。源码

       在拷贝和初始化输出流后，源码`AsyncSnapshotCallable`被创建，源码其`callInternal()`方法中负责将状态数据持久化至磁盘。源码这个过程分为几个关键步骤：

       获取`CheckpointStateOutputStream`，写入状态数据元数据，如状态名、序列化类型等。jspromise源码规范

       对状态数据按`keyGroupId`进行分组，依次将每个`keyGroupId`对应的状态数据写入文件。

       封装状态数据的元数据信息，包括存储路径和大小，以及每个`keyGroupId`在文件中的偏移位置。

       在分组过程中，状态数据首先被扁平化并添加到`partitioningSource[]`中，同时记录每个元素对应的`keyGroupId`在`counterHistogram[]`中的位置。构建直方图后，美食源码图片数据依据`keyGroupId`进行排序并写入文件，同时将偏移位置记录在`keyGroupOffsets[]`中。

       具体实现细节中，`FsCheckpointStateOutputStream`用于创建文件系统输出流，配置包括基路径、文件系统类型、缓冲大小、文件状态阈值等。`StreamStateHandle`最终封装了状态数据的小学源码编程存储文件路径和大小信息，而`KeyedStateHandle`进一步包含`StreamStateHandle`和`keyGroupRangeOffsets`，后者记录了每个`keyGroupId`在文件中的存储位置，以供状态数据检索使用。

       简而言之，Flink在执行Checkpoint时，通过一系列精心设计的步骤，确保了状态数据的高效、安全存储。从状态数据的jmqtt源码分析拷贝到元数据的写入，再到状态数据的持久化，每一个环节都充分考虑了性能和数据完整性的需求，使得Flink的实时计算能力得以充分发挥。

trainstep的checkpoint可以删吗

       不可以。根据查询CSDN网，保留trainstep的checkpoint才可以自动跟踪分配给其特性的变量，完成指令。检查点可以捕获模型使用的所有参数（tf.Variable对象）的确切值。检查点不包含对模型所定义计算的任何描述，仅在将使用保存参数值的源代码可用时才有用。

Flink mysql-cdc connector 源码解析

       Flink 1. 引入了 CDC功能，用于实时同步数据库变更。Flink CDC Connectors 提供了一组源连接器，支持从MySQL和PostgreSQL直接获取增量数据，如Debezium引擎通过日志抽取实现。以下是Flink CDC源码解析的关键部分：

       首先，MySQLTableSourceFactory是实现的核心，它通过DynamicTableSourceFactory接口构建MySQLTableSource对象，获取数据库和表的信息。MySQLTableSource的getScanRuntimeProvider方法负责创建用于读取数据的运行实例，包括DeserializationSchema转换源记录为Flink的RowData类型，并处理update操作时的前后数据。

       DebeziumSourceFunction是底层实现，继承了RichSourceFunction和checkpoint接口，确保了Exactly Once语义。open方法初始化单线程线程池以进行单线程读取，run方法中配置DebeziumEngine并监控任务状态。值得注意的是，目前只关注insert, update, delete操作，表结构变更暂不被捕捉。

       为了深入了解Flink SQL如何处理列转行、与HiveCatalog的结合、JSON数据解析、DDL属性动态修改以及WindowAssigner源码，可以查阅文章。你的支持是我写作的动力，如果文章对你有帮助，请给予点赞和关注。

       本文由文章同步助手协助完成。

Docker Checkpoint/Restore

        唔，暂时小记一下checkpoint / restore，希望之后能回顾并深入认识下目前的问题。

        CRIU全称“Checkpoint / Restore in Userspace”，是一个为Linux提供检查点/恢复功能的工具，主要是对运行中的应用进行冻结(freeze)再基于其在磁盘上的所有文件建立检查点，并根据checkpoint恢复冻结时状态并继续运行。CRIU可以运用到场景包括：应用热迁移（live migration）、快照、远程调试（debugging）等等。CRIU为OpenVZ、LXZ/LXD、Docker等都提供了很好的支持。

        /proc是一个基于内存的文件系统，包括CPU、内存、分区划分、[I/O地址]、直接内存访问通道和正在运行的进程等等，Linux通过/proc访问内核内部数据结构及更改内核设置等。Checkpoint很大程度上是基于/proc文件系统进行的，主要依赖/proc获取文件描述符信息、管道参数、内存映射等。

        Checkpoint通过进程转存器(process dumper)进行以下步骤：

        Restore恢复过程主要进行以下步骤：

        Docker container实际上也是一个进程，故CRIU实质上是对容器进程进行checkpoint/restore。

        源码装CRIU有一丢丢麻烦，记得把官网说的那些库都下完整哦。

        docker虽然提供了checkpoint，但切换至experimental下才能用，新建/etc/docker/daemon.json文件，（docker的配置文件，默认没有）。

        若该文件参数更改很多，就会起冲突......解决办法：尽量只将自己需要更改的配置参数写入就好，若还冲突，就启动docker时手动指定参数或脚本启动吧。

        另外，我使用docker 及之后的版本时，checkpoint无法正常使用，主要出现以下问题：

        据说是moby的原因，但看Stackflow上的问题也还是open的，关闭了一个但感觉他关的莫名其妙；有一个问题下，开发人员说解决了，但还未推到新版本。我的解决办法：试验之后，建议使用较新版本.进行checkpoint/restore，可以正常使用，可能版本（小生年方，尚未婚娶）太新了脚跟还没站稳。

        现在可以开始愉快地使用docker checkpoint了！！Docker CLI提供了checkpoint命令。

        create

        ls

        rm无话可说

        start

        启动时没有单独的命令，但在container start可以指定checkpoint选项参数，如将容器从/home/vickee/chkps/目录下的chkp0恢复：

        注意：在创建checkpoint时，若我们指定的路径为/home/PATH，则恢复时还需要具体指定到该路径下的/home/PATH/[CONTAINER_FULL_ID]/checkpoints。因为恢复时，我们可能新建容器，或者将另一个容器从别的容器的checkpoint恢复，故需自己根据checkpoint信息进行路径完善。

        CRIU对最新内核的支持有限，且好像在较新版本中，移除了--checkpoint-dir即指定目录这一特性。

        若容器运行时有用external terminal（ docker run -t ），checkpoint会失败的。[ 参数-t 让docker分配一个伪终端并绑定到容器的标准输入上, -i 则让容器的标准输入保持打开，常一起使用。]

        links：

        https://criu.org/Docker

        https://criu.org/Installation

        https://criu.org/Checkpoint/Restore