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`实现。源码在进行状态数据的源码翼支付模板源码快照操作时,首先对状态数据进行拷贝,源码这里采取的源码是引用拷贝而非实例拷贝,速度快且占用内存较少。源码拷贝后的源码状态数据被写入到一个临时的`CheckpointStateOutputStream`,即`$CHECKPOINT_DIR/$UID/chk-n`格式的源码目录,这个并非最终数据存储位置。源码
在拷贝和初始化输出流后,源码`AsyncSnapshotCallable`被创建,源码其`callInternal()`方法中负责将状态数据持久化至磁盘。源码闹钟 源码这个过程分为几个关键步骤:
获取`CheckpointStateOutputStream`,写入状态数据元数据,如状态名、序列化类型等。
对状态数据按`keyGroupId`进行分组,依次将每个`keyGroupId`对应的状态数据写入文件。
封装状态数据的元数据信息,包括存储路径和大小,以及每个`keyGroupId`在文件中的偏移位置。
在分组过程中,状态数据首先被扁平化并添加到`partitioningSource[]`中,同时记录每个元素对应的`keyGroupId`在`counterHistogram[]`中的位置。构建直方图后,数据依据`keyGroupId`进行排序并写入文件,atan源码同时将偏移位置记录在`keyGroupOffsets[]`中。具体实现细节中,`FsCheckpointStateOutputStream`用于创建文件系统输出流,配置包括基路径、文件系统类型、缓冲大小、文件状态阈值等。`StreamStateHandle`最终封装了状态数据的存储文件路径和大小信息,而`KeyedStateHandle`进一步包含`StreamStateHandle`和`keyGroupRangeOffsets`,后者记录了每个`keyGroupId`在文件中的存储位置,以供状态数据检索使用。
简而言之,Flink在执行Checkpoint时,通过一系列精心设计的聊聊源码步骤,确保了状态数据的高效、安全存储。从状态数据的拷贝到元数据的写入,再到状态数据的持久化,每一个环节都充分考虑了性能和数据完整性的需求,使得Flink的实时计算能力得以充分发挥。
RocketMQ 5.0: POP 消费模式 原理详解 & 源码解析
RocketMQ 5.0 引入 Pop 消费模式,用于解决 Push 消费模式存在的痛点。Pop 消费模式将客户端的重平衡逻辑迁移至 Broker 端,使得消息消费过程更加高效,避免消息堆积和横向扩展能力受限的问题。引入轻量化客户端后,通过 gRPC 封装 Pop 消费接口,实现了多语言支持,牛蒡源码无需在客户端实现重平衡逻辑。
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源码,可以查阅文章。你的支持是我写作的动力,如果文章对你有帮助,请给予点赞和关注。
本文由文章同步助手协助完成。