把状态写在磁盘上：我用文件系统给无人值守任务做了个状态机

我有一条每天自动发文的流水线：生成稿子、落盘、调脚本发布。跑了两周后，问题开始集中出现——同一天因为手动补跑了一次，脚本把同一篇文章发了两遍；某次机器休眠中断，重启后不知道哪些环节完成过，只好整条重来；还有一次定时任务和手动执行撞在一起，两个进程同时往目标目录写，出了半截文件。

这些问题的共性不是"脚本写错了"，而是**任务没有状态**。一个只有输入和输出的脚本，本质上是一次性的；一旦它被放进无人值守的环境，就必须回答三个问题：我做过没有？我做到哪了？现在有没有别人在做？

多数人的第一反应是上数据库或 Redis。但对单机、单用户、每天只跑几次的任务来说，引入一个常驻服务的运维成本远高于收益。我的选择是：**把状态写在磁盘上，用文件系统的原子操作当并发原语。**

文件系统能提供的原子性其实只有三条，但组合起来足够撑起一个小型状态机：

1. **原子创建**（`O_CREAT | O_EXCL`）：同名文件不存在才创建成功，用来实现"抢占锁"。

2. **原子重命名**（同分区 `rename`）：要么旧名在，要么新名在，不会出现中间态，用来"发布"一个结果。

3. **mtime**：文件的最后修改时间，用来做时间判断，比如锁是否过期。

关键是第三条的正确用法：**不要用"当前时间大于某时刻"来判定**，而要用"现在 - mtime > 阈值"。这样即使时钟有轻微回拨，判断也不会翻车。

目录即状态：我的三类文件约定

我在任务根目录下固定开了三个子目录，语义全部由路径承载：

- `done/`：幂等账本。文件名就是业务键，比如 `2026-10-02.md`。任务启动第一件事就是检查 `done/<today>` 是否存在，存在直接退出。这样无论重跑多少次，发布永远只发生一次。

- `locks/`：抢占锁。`locks/publish.lock` 里写进程 PID 和启动时间。抢到锁的进程负责干活，抢不到的直接退出，绝不排队等待——等待只会让重复发布的可能性变大。

- `stages/`：断点。把长任务切成 `01_generate`、`02_write`、`03_publish` 三个标记文件，每完成一步落一个。重启后从第一个缺失的 stage 开始，而不是从头再来。

Python 里实现原子抢锁只要几行，注意必须用 `O_EXCL`，先判断再创建会有竞态：

def acquire(lock_path, stale_seconds=1800):

payload = json.dumps({"pid": os.getpid(), "at": time.time()})

fd = os.open(lock_path, os.O_CREAT | os.O_EXCL | os.O_WRONLY)

陈旧锁回收：上次进程被杀，锁没释放

if time.time() - os.path.getmtime(lock_path) > stale_seconds:

这里有个坑值得单独说：`stale_seconds` 不能设得太短。我有次把它设成 300 秒，结果发布环节因为网络慢卡了 6 分钟，第二个进程判定锁过期、把锁删了，两篇稿子一起飞了出去。**锁的超时必须大于任务 P95 耗时**，这是硬约束。

改造之后，流水线变得可以"随便重跑"：补跑、中断恢复、并发撞击这三个场景都不再产生脏结果。踩过的坑也一并记下来：

- **不是所有文件系统都保证原子 rename**。本地盘、ext4、NTFS 都没问题，但网络盘和部分同步云盘的 rename 语义不保证，跨分区 rename 甚至会退化成"复制+删除"。状态文件一律放本地盘。

- **杀进程会留下残留锁**。所以必须有基于 mtime 的陈旧锁回收，否则一次异常就让明天的任务全被挡住。回收逻辑本身要小心，最好带上 PID 存活检查。

- **标记文件别当真相**。`done/` 是"已经完成"的证据，不是"应该完成"的清单。别用它反推任务有没有该跑——一旦某天的文件被人手动删了，账本就会谎报军情。

这套方案有明确的边界，越界就要老实地换工具：出现**多台机器、多个写者、需要按时间范围查询历史执行记录**这三种情况中的任意一种，文件系统就不再够用，该上 SQLite 或 Postgres。我自己的判断线是：只要状态是"每台机器各自维护、只用于跳过和自我恢复"，文件就够了。

1. 无人值守的任务，先设计状态，再写业务逻辑。

2. 幂等不是靠"小心"，而是靠一个原子的、落在磁盘上的账本。

3. 所有超时阈值都要大于任务的 P95 耗时，否则你会亲手制造并发。

把状态写在磁盘上，本质上是用最简单的介质换取了可恢复性。它不优雅，但足够可靠——对于每天替你干活的脚本来说，可靠比优雅重要得多。

用文件系统的原子操作给无人值守任务做状态机：幂等账本、抢占锁与断点续跑

后端

编程语言

操作系统

用文件系统原子操作实现无人值守任务状态机：通过`done/`幂等账本、`locks/`抢占锁（含mtime陈旧回收）、`stages/`断点标记，解决重复发布、中断恢复与并发冲突。Python `O_EXCL`抢锁代码实战验证，锁超时须大于任务P95耗时。附边界条件：网络盘rename不保证、杀进程残留锁处理、避免将标记文件当真相。

文件系统

数据库

SQLite

Python

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用文件系统原子操作实现无人值守任务状态机：通过`done/`幂等账本、`locks/`抢占锁（含mtime陈旧回收）、`stages/`断点标记，解决重复发布、中断恢复与并发冲突。Python `O_EXCL`抢锁代码实战验证，锁超时须大于任务P95耗时。附边界条件：网络盘rename不保证、杀进程残留锁处理、避免将标...

把状态写在磁盘上：我用文件系统给无人值守任务做了个状态机

把状态写在磁盘上：我用文件系统给无人值守任务做了个状态机

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐