任务处理场景下长时间（数日至数周）锁定数据库行是否可行？

长周期任务持有排他锁方案评估 #

该方案完全不具备生产可行性，核心问题如下：

• 数据库排他锁的设计目标是支撑短事务场景，持有锁的事务需要维持数据库连接，根本不可能稳定持有1个月的连接，中间出现网络波动、数据库重启、worker进程崩溃等异常时，锁会永久残留无法释放，直接导致对应任务甚至整个调度流程卡死。
• 即使不考虑异常场景，长持有锁会导致所有对该任务行的修改操作全部阻塞，无法调整任务参数、重置任务状态，运维灵活性为0。
• 几乎所有数据库的默认事务超时、锁超时配置都在小时级以内，强行修改配置适配月级长事务会大幅降低整个数据库的容错能力，极易引发全库级别的性能故障。

worker关联+健康检查方案说明 #

该方案是当前分布式任务调度的主流落地方案，可行性很高，推荐的表结构调整如下：

-- 原有tasks表新增字段
ALTER TABLE tasks 
ADD COLUMN worker_id UUID,
ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending', -- 任务状态：pending待分配/assigned已分配/running执行中/finished已完成/failed执行失败
ADD COLUMN assigned_at TIMESTAMP,
ADD COLUMN last_heartbeat TIMESTAMP;

-- 新增worker追踪表
CREATE TABLE workers (
  id UUID PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  status VARCHAR(20) NOT NULL DEFAULT 'online', -- worker状态：online在线/offline下线/down失联
  last_heartbeat TIMESTAMP NOT NULL DEFAULT NOW(),
  max_concurrent_tasks INT NOT NULL DEFAULT 10
);

核心调度逻辑完全不需要手动加锁，利用数据库条件更新的原子性即可避免任务抢锁冲突：

-- 任务分配时的原子更新语句，PostgreSQL语法示例，MySQL可调整为对应语法
UPDATE tasks 
SET status = 'assigned', worker_id = '当前待分配的workerID', assigned_at = NOW(), last_heartbeat = NOW()
WHERE status = 'pending'
ORDER BY id ASC
LIMIT 1
RETURNING *;

生产实践建议 #

• 健康检查定时执行，可按10-30分钟的间隔扫描任务表，将满足status IN ('assigned', 'running') AND last_heartbeat < NOW() - 1小时且对应worker状态为失联的任务，重置为pending状态重新分配，阈值可根据任务实际执行周期调整，避免误回收正常执行的任务。
• worker执行任务过程中，每5-10分钟主动更新一次所持任务的last_heartbeat字段，开销极低且能保证任务状态的准确性。
• 给tasks表的(status, last_heartbeat)字段建联合索引，避免健康检查、任务分配时扫全表，影响性能。
• 不要将任务生命周期和数据库事务绑定，任务状态的流转完全由业务逻辑管控，数据库仅做状态存储。

内容的提问来源于stack exchange，提问作者typicallearner