1.Flink源码分析——Checkpoint源码分析(二)
2.RocketMQ 5.0: POP 消费模式 原理详解 & 源码解析
3.trainstep的源码checkpoint可以删吗
4.Docker Checkpoint/Restore
5.Flink mysql-cdc connector 源码解析

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

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

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

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

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

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

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

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

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

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

RocketMQ 5.0: POP 消费模式 原理详解 & 源码解析

       RocketMQ 5.0 引入 Pop 消费模式，用于解决 Push 消费模式存在的痛点。Pop 消费模式将客户端的重平衡逻辑迁移至 Broker 端，使得消息消费过程更加高效，避免消息堆积和横向扩展能力受限的问题。引入轻量化客户端后，通过 gRPC 封装 Pop 消费接口，实现了多语言支持，python打印日历源码无需在客户端实现重平衡逻辑。

       Pop 消费模式的原理在于客户端仅需发送 Pop 请求，由 Broker 端根据请求分配消息队列并返回消息。这样可以实现多客户端同时消费同一队列，避免单一客户端挂起导致消息堆积，同时也消除了频繁重平衡导致的消息积压问题。

       Pop 消费流程涉及消息拉取、不可见时间管理、消费失败处理和消息重试等关键环节。消息拉取时，系统会为一批消息生成 CheckPoint，并在 Broker 内存中保存，以便与 ACK 消息匹配。消息不可见时间机制确保在规定时间内未被 ACK 的消息将被重试。消费失败时，客户端通过修改消息不可见时间来调整重试策略。当消费用时超过预设时间，Broker 也会将消息放入重试队列。通过定时消息，Broker 可以提前消费重试队列中的消息，与 ACK 消息匹配，实现高效消息处理。

       在 Broker 端，重平衡逻辑也进行了优化。Pop 模式的重平衡允许多个消费者同时消费同一队列，通过 popShareQueueNum 参数配置额外的负载获取队列次数。Pop 消息处理涉及从队列中 POP 消息、生成 CheckPoint 用于匹配 ACK 消息、以及存储 CheckPoint 与 Ack 消息匹配。Broker 端还通过 PopBufferMergeService 线程实现内存与磁盘中的 CheckPoint 和 Ack 消息匹配，以及消息重试处理。

       源码解析部分涉及 Broker 端的重平衡逻辑、Pop 消息处理、Ack 消息处理、CheckPoint 与 Ack 消息匹配逻辑等关键组件的实现细节，这些细节展示了 RocketMQ 5.0 如何通过优化消费模式和流程设计，提升消息消费的效率和稳定性。

trainstep的checkpoint可以删吗

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

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

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源码，可以查阅文章。你的支持是我写作的动力，如果文章对你有帮助，请给予点赞和关注。

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