GLM-OCR任务恢复机制解读服务重启后任务如何无缝接续【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCRGLM-OCR是一款基于 FastAPI 的开源 OCR 文档识别服务支持 PDF 与图片的智能识别、版面分析并输出 Markdown / JSON 结构化结果。对使用者来说最让人头疼的场景是一份几百页的 PDF 识别到一半服务恰好重启了任务会不会丢这篇文章解读 GLM-OCR 内置的任务恢复机制讲清楚服务重启后任务如何靠「数据库持久化 分布式锁 自动重试」无缝接续。一、为什么任务恢复对 OCR 服务至关重要OCR 任务天然耗时一份长文档要走「PDF 转图片 → 版面分析 OCR 识别 → 结果合并」三步流水线见 pipeline_flow.py动辄几分钟到几十分钟。这期间随时可能遇到意外 服务发布、更新进程被重启 Worker 进程异常崩溃⚡ 长时间任务被误判为「卡死」如果任务状态只存在内存里重启等于任务全部清零。GLM-OCR 的做法是任务状态永远落在数据库里默认 SQLite可在 config.py 中改DATABASE_URL进程只是「临时工」数据库才是任务的「家」。二、任务档案数据库里存了哪些恢复线索每个任务在数据库tasks表中都有一行完整档案模型定义见 task.py。与恢复机制直接相关的字段有字段作用status当前状态pending / processing / completed / failed / dead_letterworker_id正在处理该任务的 Workerlock_expires_at锁的过期时间判断任务是否「失联」的关键retry_count/max_retries已重试次数 / 最大重试次数默认 3 次progress/current_step进度与当前步骤恢复后从 0 重新起跑上图为 GLM-OCR 识别论文页面后的版面区域这类长文档任务正是恢复机制要保护的对象。三、启动恢复流程重启后第一件事服务启动时的动作链在 main.py 的生命周期钩子里初始化数据库 →init_task_system()启动任务系统。task_manager.py 的start()方法中先恢复任务、再拉起 Worker顺序很关键——避免新 Worker 抢走本该被清理的「僵尸任务」。恢复逻辑集中在 recovery_handler.py扫描所有「仍在 processing 但锁已过期」的任务get_expired_locks对每个任务判断can_retry✅还能重试状态重置回pending清空worker_id、lock_expires_at、started_at、progress并把retry_count加 1等待空闲 Worker 重新领取❌重试次数耗尽直接标记为dead_letter死信记录原因「max retries exceeded」留待人工排查。这样重启后原本「跑到一半」的任务会自动回到待处理队列用户侧看到的是任务继续推进而无需重新提交。任务最终产出的识别内容示例——恢复机制保证的就是这类结果不被中途打断。四、分布式锁与超时防止「任务被抢」或「任务失联」重启恢复之外GLM-OCR 还有一套锁机制防止多 Worker 并发下的两类事故核心实现见 lock_manager.py原子加锁Worker 领取任务时worker.py 的_acquire_task通过一条带 WHERE 条件的 UPDATE 语句抢锁同时把状态置为processing并写入锁过期时间。条件里特意允许「锁已过期的 processing 任务也能被重新获取」——这既是防重复处理也是防失联兜底。⏰超时自动释放默认TASK_TIMEOUT3600秒。锁过期后任务即使还挂着 processing 状态也可以被其他 Worker 重新捞起。️监控协程兜底task_manager.py 中还有一个后台监控循环_monitoring_loop按METRICS_INTERVAL默认 60 秒周期性调用recover_expired_locks把运行期间就发现的任务锁过期问题实时修复而不必等到下次重启。简单说Worker 死了锁会过期锁过期了任务自动归队。这就是「无缝接续」的底层保障。五、自动重试与死信失败的出路任务处理中抛异常时走 retry_handler.py 的分流逻辑⏳可重试错误超时、连接错误、限流等按「指数退避 随机抖动」策略延迟后重置为 pending默认最多重试 3 次DEFAULT_MAX_RETRIES不可重试错误文件不存在、参数校验失败等不浪费算力反复重试直接进死信队列死信dead_letter最终失败的任务不会消失而是带着完整错误信息留存方便通过任务列表接口定位原因。相关数据访问逻辑抢锁、续期、重置、查过期锁统一封装在 repository/task.py。六、实用配置速查调优恢复行为在 config.py 或通过.env调整配置项默认值建议TASK_TIMEOUT3600 秒大文档可加大让锁更「耐死」WORKER_COUNT5按机器资源调整恢复后任务由它们接管METRICS_INTERVAL60 秒缩小可让运行期锁恢复更及时DEFAULT_MAX_RETRIES3网络不稳的环境可适当调大如需在本地体验完整链路可以克隆仓库后启动后端git clone https://gitcode.com/GitHub_Trending/gl/GLM-OCR七、总结GLM-OCR 的任务恢复机制可以概括为三句话状态落库任务档案状态、进度、锁、重试次数持久化在数据库中进程重启不丢数据锁会过期分布式锁 超时回收让崩溃 Worker 留下的任务自动回到 pending 队列由监控协程实时兜底失败有出口自动重试负责扛住瞬时故障死信队列负责留住无法自愈的问题任务。对新手而言理解这套机制后你就不必担心「重启会丢任务」——这正是生产级异步 OCR 服务与普通脚本的本质区别。【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GLM-OCR任务恢复机制解读：服务重启后任务如何无缝接续
GLM-OCR任务恢复机制解读服务重启后任务如何无缝接续【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCRGLM-OCR是一款基于 FastAPI 的开源 OCR 文档识别服务支持 PDF 与图片的智能识别、版面分析并输出 Markdown / JSON 结构化结果。对使用者来说最让人头疼的场景是一份几百页的 PDF 识别到一半服务恰好重启了任务会不会丢这篇文章解读 GLM-OCR 内置的任务恢复机制讲清楚服务重启后任务如何靠「数据库持久化 分布式锁 自动重试」无缝接续。一、为什么任务恢复对 OCR 服务至关重要OCR 任务天然耗时一份长文档要走「PDF 转图片 → 版面分析 OCR 识别 → 结果合并」三步流水线见 pipeline_flow.py动辄几分钟到几十分钟。这期间随时可能遇到意外 服务发布、更新进程被重启 Worker 进程异常崩溃⚡ 长时间任务被误判为「卡死」如果任务状态只存在内存里重启等于任务全部清零。GLM-OCR 的做法是任务状态永远落在数据库里默认 SQLite可在 config.py 中改DATABASE_URL进程只是「临时工」数据库才是任务的「家」。二、任务档案数据库里存了哪些恢复线索每个任务在数据库tasks表中都有一行完整档案模型定义见 task.py。与恢复机制直接相关的字段有字段作用status当前状态pending / processing / completed / failed / dead_letterworker_id正在处理该任务的 Workerlock_expires_at锁的过期时间判断任务是否「失联」的关键retry_count/max_retries已重试次数 / 最大重试次数默认 3 次progress/current_step进度与当前步骤恢复后从 0 重新起跑上图为 GLM-OCR 识别论文页面后的版面区域这类长文档任务正是恢复机制要保护的对象。三、启动恢复流程重启后第一件事服务启动时的动作链在 main.py 的生命周期钩子里初始化数据库 →init_task_system()启动任务系统。task_manager.py 的start()方法中先恢复任务、再拉起 Worker顺序很关键——避免新 Worker 抢走本该被清理的「僵尸任务」。恢复逻辑集中在 recovery_handler.py扫描所有「仍在 processing 但锁已过期」的任务get_expired_locks对每个任务判断can_retry✅还能重试状态重置回pending清空worker_id、lock_expires_at、started_at、progress并把retry_count加 1等待空闲 Worker 重新领取❌重试次数耗尽直接标记为dead_letter死信记录原因「max retries exceeded」留待人工排查。这样重启后原本「跑到一半」的任务会自动回到待处理队列用户侧看到的是任务继续推进而无需重新提交。任务最终产出的识别内容示例——恢复机制保证的就是这类结果不被中途打断。四、分布式锁与超时防止「任务被抢」或「任务失联」重启恢复之外GLM-OCR 还有一套锁机制防止多 Worker 并发下的两类事故核心实现见 lock_manager.py原子加锁Worker 领取任务时worker.py 的_acquire_task通过一条带 WHERE 条件的 UPDATE 语句抢锁同时把状态置为processing并写入锁过期时间。条件里特意允许「锁已过期的 processing 任务也能被重新获取」——这既是防重复处理也是防失联兜底。⏰超时自动释放默认TASK_TIMEOUT3600秒。锁过期后任务即使还挂着 processing 状态也可以被其他 Worker 重新捞起。️监控协程兜底task_manager.py 中还有一个后台监控循环_monitoring_loop按METRICS_INTERVAL默认 60 秒周期性调用recover_expired_locks把运行期间就发现的任务锁过期问题实时修复而不必等到下次重启。简单说Worker 死了锁会过期锁过期了任务自动归队。这就是「无缝接续」的底层保障。五、自动重试与死信失败的出路任务处理中抛异常时走 retry_handler.py 的分流逻辑⏳可重试错误超时、连接错误、限流等按「指数退避 随机抖动」策略延迟后重置为 pending默认最多重试 3 次DEFAULT_MAX_RETRIES不可重试错误文件不存在、参数校验失败等不浪费算力反复重试直接进死信队列死信dead_letter最终失败的任务不会消失而是带着完整错误信息留存方便通过任务列表接口定位原因。相关数据访问逻辑抢锁、续期、重置、查过期锁统一封装在 repository/task.py。六、实用配置速查调优恢复行为在 config.py 或通过.env调整配置项默认值建议TASK_TIMEOUT3600 秒大文档可加大让锁更「耐死」WORKER_COUNT5按机器资源调整恢复后任务由它们接管METRICS_INTERVAL60 秒缩小可让运行期锁恢复更及时DEFAULT_MAX_RETRIES3网络不稳的环境可适当调大如需在本地体验完整链路可以克隆仓库后启动后端git clone https://gitcode.com/GitHub_Trending/gl/GLM-OCR七、总结GLM-OCR 的任务恢复机制可以概括为三句话状态落库任务档案状态、进度、锁、重试次数持久化在数据库中进程重启不丢数据锁会过期分布式锁 超时回收让崩溃 Worker 留下的任务自动回到 pending 队列由监控协程实时兜底失败有出口自动重试负责扛住瞬时故障死信队列负责留住无法自愈的问题任务。对新手而言理解这套机制后你就不必担心「重启会丢任务」——这正是生产级异步 OCR 服务与普通脚本的本质区别。【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考