MySQL 8.0 SKIP LOCKED 怎么做任务抢占：锁范围、空队列与重复消费验收

订单导出、图片转码这类后台任务，多实例部署后最容易踩的坑就是两个 worker 同时读到同一条待处理记录。MySQL 8.0 的 SKIP LOCKED 可以让已经被别的事务锁住的行暂时跳过，但它不是开箱即用的自动去重开关。真正可靠的做法是用短事务锁定一小批任务，立刻改成处理中状态，再靠租约、幂等键和回收流程兜住所有异常场景。

先把任务表设计成可抢占的队列

示例表叫 job_queue。status 只保留几个有明确含义的枚举值：ready 表示可领取，running 表示已经被某个 worker 拿走处理，done 和 failed 负责标记最终处理结果。不要让消费者靠一串含义模糊的数字状态去猜当前任务走到了哪个业务阶段。

CREATE TABLE job_queue (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  task_key VARCHAR(80) NOT NULL,
  payload JSON NOT NULL,
  status ENUM('ready', 'running', 'done', 'failed') NOT NULL,
  lease_owner VARCHAR(64) NULL,
  lease_until DATETIME(6) NULL,
  attempts INT NOT NULL DEFAULT 0,
  created_at DATETIME(6) NOT NULL,
  updated_at DATETIME(6) NOT NULL,
  UNIQUE KEY uk_task_key (task_key),
  KEY ix_ready_pick (status, lease_until, id)
) ENGINE=InnoDB;

ix_ready_pick 不是为了让全表查询速度变快，而是把“可领取”的候选行范围尽量缩小。如果要把已经过期的 running 任务也纳入领取逻辑，要在查询条件里明确写出来，成功更新状态时再做一次当前状态的二次校验。

最小抢占实现逻辑：锁定、改状态、提交

更推荐把“选任务”和“改任务状态”放在同一个极短的事务里执行。下面的查询每次只取一条任务，按创建时间和主键排序，多个 worker 碰到同一行数据时，后发起的事务会直接跳过已经被锁住的记录，不会进入锁等待。

START TRANSACTION;

SELECT id, task_key, payload
FROM job_queue
WHERE status = 'ready'
ORDER BY created_at, id
LIMIT 1
FOR UPDATE SKIP LOCKED;

UPDATE job_queue
SET status = 'running',
    lease_owner = 'worker-03',
    lease_until = UTC_TIMESTAMP(6) + INTERVAL 2 MINUTE,
    attempts = attempts + 1,
    updated_at = UTC_TIMESTAMP(6)
WHERE id = 7412
  AND status = 'ready';

COMMIT;

应用层要做两层校验：查询结果有没有返回行，以及更新语句的影响行数是不是 1。如果更新返回影响行数为 0，就不要继续处理读到的旧数据，说明这条任务已经被另一个 worker 抢先改走了。等事务提交之后再开始真正的导出或者转码逻辑，这样耗时很长的业务操作不会把行锁一直占着，拖慢整个队列的领取效率。

为什么不能在事务里处理文件和网络请求

SKIP LOCKED 只解决行之间的锁竞争问题，不会缩短事务本身的耗时。如果 worker 在事务里上传 500 MB 的大文件，其他消费者会不断跳过这行，队列看起来就像凭空少了一条待处理任务，数据库连接也会被长时间占用，很快耗尽连接池配额。锁定阶段只留任务 ID、租约所有者和起始状态，所有外部 IO 操作都放到事务提交之后再执行。

空队列不是异常：把三种结果分开统计

抢占查询返回 0 行时，至少对应三种不同场景：表里根本没有 ready 任务；有任务但全部被其他事务锁住；只有 running 任务等着租约过期回收。消费者不该把这三种情况都记成数据库错误，否则正常空闲时段也会刷爆告警。

别上来就把轮询间隔调到 10 毫秒，队列长期为空时用指数退避策略能大幅降低无效查询数量，有新任务写入时再通过应用层通知或者定时唤醒机制缩短延迟。

租约与幂等键，才是避免重复消费的最后防线

worker 拿到任务后可能被 OOM 杀掉，也可能处理成功但在写回 done 前遇到网络断开。因此 running 不能永久保持占用状态。回收逻辑只能回收租约已经过期的记录，还要做状态校验避免覆盖已经被新 worker 续租的任务。

UPDATE job_queue
SET status = 'ready',
    lease_owner = NULL,
    lease_until = NULL,
    updated_at = UTC_TIMESTAMP(6)
WHERE status = 'running'
  AND lease_until 

业务侧的最终结果还是要按 task_key 或者下游服务的幂等键做去重。比如同一份订单导出任务即使被重试两次，也只能生成一个最终的文件记录。数据库锁只能保护领取瞬间的互斥，没法替你约束跨库、跨服务的业务副作用。

上线前用四组并发测试做验收

别只在单线程脚本里看到一条任务从 ready 变成 running 就觉得功能没问题。至少准备 10 条测试任务、3 个并发 worker 和一个故意暂停的事务，核对下面四组结果：

• 同一行竞争：只有一个 worker 拿到该任务 ID，其余 worker 不会进入锁等待，直接尝试获取下一条任务。
• 空队列：返回空结果时进程保持健康，日志能区分正常空闲和真实 SQL 错误。
• 崩溃恢复：持有租约的 worker 被直接终止，超过租约时长后任务能回到 ready 状态，重试次数 attempts 不会丢失。
• 重复消息：相同 task_key 的任务重放时，下游业务只产生一个结果，重复请求能留下明确日志记录。

还要确认复制拓扑的限制。官方文档明确说明，NOWAIT 和 SKIP LOCKED 对基于语句的复制模式不安全，生产环境要提前核对 binlog 格式、读写路由规则和实际使用的存储引擎，不要把锁队列查询误发到只读副本上。

相关问题

SKIP LOCKED 会不会保证任务严格按顺序处理？

不会。它允许跳过被锁住的行，因此只能保证当前可见候选范围内的某种领取顺序，没法实现全局严格 FIFO。如果需要严格顺序执行，可以按业务维度做分片，或者用单独的顺序协调机制处理。

什么时候应该用 NOWAIT 而不是 SKIP LOCKED？

需要马上感知“拿不到锁”，由应用层直接决定失败、降级或者重试的场景，用 NOWAIT；需要继续遍历找其他可处理任务的队列消费者场景，更适合用 SKIP LOCKED。

查询没有返回任务，能说明队列真的为空吗？

不能。可能是候选行正在被其他事务锁住，也可能所有任务都处于 running 占用状态。把空结果次数、跳过次数和租约回收数分别做埋点统计，判断队列状态才不会失真。

把数据库锁当作领取凭证，而不是业务结果

MySQL 8.0 的 SKIP LOCKED 很适合降低队列消费者之间的锁等待冲突，但它的边界也很清晰：返回的结果视图可能不是全量一致的，事务必须做的足够短，锁定后的业务处理绝对不能拖在事务里，最终结果正确性还要靠租约和幂等键做兜底。把这几层职责拆开，多个 worker 才能在高峰期平稳推进任务，偶发的进程崩溃也有可回收、可重放的完整路径。