linux定时任务需保障幂等性，核心是任务自身判断是否已执行：用mkdir原子创建锁目录实现单机互斥；对周期性任务可记录上次执行时间或用数据库字段校验；分布式场景宜用redis setnx、zookeeper等协调服务；根本解法是设计天然幂等的任务逻辑。
Linux定时任务重复执行时，必须考虑幂等性——即同一任务多次运行不会产生副作用。核心思路是：让任务自身具备“判断是否已执行过”的能力，而不是依赖外部调度器保证不重复。
使用锁文件（Lock File）机制
在任务开始前创建一个带时间戳的临时锁文件，执行完成后删除；若锁文件存在且未超时，则跳过本次执行。
- 用
mkdir实现原子加锁（比 touch + 判断更可靠），因为目录创建是原子操作 - 示例脚本片段：
LOCKDIR="/tmp/myjob.lock" if mkdir "$LOCKDIR" 2>/dev/null; then # 成功获取锁，执行主逻辑 trap 'rmdir "$LOCKDIR"' EXIT # ... your actual job here ... else echo "Job is already running or recently finished" exit 0 fi
- 注意：不要仅依赖 PID 文件，进程可能异常退出导致残留
基于时间窗口或状态标记的去重
适用于有明确执行周期、且可接受“最多执行一次/每X分钟”的场景。
- 记录上次成功执行时间（如写入
/var/run/myjob.last），每次运行前检查间隔是否达标 - 对数据库类任务，可在表中增加
last_run_at字段或专用状态表，用 SQL 判断+更新实现条件执行 - 避免用系统时间做唯一依据，要考虑时钟回拨；推荐用单调递增标识（如 Redis INCR、数据库自增 ID）辅助判断
利用外部协调服务（适合分布式环境）
单机锁文件在多节点部署下失效，需升级为分布式锁。
- Redis + SETNX（或 Redlock）：设置带过期时间的 key，获取成功才执行
- ZooKeeper 或 etcd：通过临时有序节点实现选举和互斥
- 云平台方案：如 AWS Step Functions、阿里云SchedulerX，自带任务去重和状态追踪能力
任务设计本身支持重复安全
这是最根本的解决方式——让任务逻辑天然幂等。
- 数据库操作优先用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或INSERT IGNORE（MySQL） - 文件处理前先校验目标是否存在、内容是否一致（如用 sha256sum 比对）
- API 调用携带唯一请求 ID（idempotency key），由服务端保障幂等
- 避免使用
append类操作，改用覆盖或版本化存储
