MySQL SKIP LOCKED 怎么实现多消费者任务领取

要让多个消费者并行领取 MySQL 任务，关键不是把查询做得更快，而是把“选中任务”和“改成处理中”放进同一个短事务。领取时使用 SELECT ... FOR UPDATE SKIP LOCKED：已经被其他事务锁住的行会被跳过，每个消费者因此取得不同批次；提交后再执行耗时业务。

SKIP LOCKED 适合队列表的竞争领取，但它返回的不是一致性视图。它不应替代普通业务查询，也不能单独保证任务永不重复执行。

先查后改为什么会重复领取

如果消费者先用普通 SELECT 找到 ready 任务，离开事务后再执行 UPDATE，另一个消费者可能在间隙读取到同一批行。普通一致性读不会替你保留这些任务。

CREATE TABLE task_queue (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    status ENUM('ready','running','done','failed') NOT NULL DEFAULT 'ready',
    available_at DATETIME(6) NOT NULL,
    worker_id VARCHAR(64),
    lease_token CHAR(36),
    locked_at DATETIME(6),
    payload JSON NOT NULL,
    -- 先按状态过滤，再按可执行时间和主键稳定领取。
    KEY idx_claim (status, available_at, id)
) ENGINE=InnoDB;

索引的作用不仅是提速，也会缩小锁定读需要检查的范围。领取顺序使用 available_at, id，在时间相同时仍有稳定次序。

在一个短事务里锁定并迁移状态

每个消费者开启事务，锁定一小批可执行任务。SKIP LOCKED 不等待别人的行锁，而是直接跳过；应用拿到 ID 后，仍在同一事务中写入工作进程与租约令牌。

START TRANSACTION;

-- 已被其他消费者锁定的任务不会出现在本批结果中。
SELECT id
FROM task_queue
WHERE status = 'ready'
  AND available_at 

锁定读必须处在显式事务中；提交或回滚会释放锁。不要在事务里调用外部接口、生成文件或执行分钟级计算，否则行锁会一直占用。

提交后处理，并用租约确认结果

领取事务提交后，消费者根据 payload 执行业务。完成时不仅匹配任务 ID，还要匹配本次 lease_token，这样旧消费者即使迟到，也不能覆盖后来重新领取的状态。

-- 只有当前租约持有者能够确认完成。
UPDATE task_queue
SET status = 'done'
WHERE id = ?
  AND status = 'running'
  AND lease_token = ?;

若受影响行数为 0，说明任务已经被回收、重领或完成，当前消费者应停止提交结果。业务写入还应使用任务 ID 或业务单号建立唯一约束，因为消费者在提交结果前崩溃时，任务仍可能被再次执行。

超时回收要和幂等一起设计

定时回收超过租约时间的 running 任务，让它重新变为 ready。租约时长应大于常规处理耗时，并对长任务提供续租机制。

-- 回收超过五分钟仍未完成的租约，等待下一轮领取。
UPDATE task_queue
SET status = 'ready',
    worker_id = NULL,
    lease_token = NULL,
    locked_at = NULL
WHERE status = 'running'
  AND locked_at 

常见问题

为什么不用 NOWAIT？

NOWAIT 遇到锁会立即报错；SKIP LOCKED 会省略锁定行并继续返回其他任务，更符合多消费者队列的领取需求。

复制环境需要注意什么？

MySQL 官方文档指出，含 NOWAIT 或 SKIP LOCKED 的语句对 statement-based replication 不安全。使用这类领取方式时，应确认复制格式和部署约束。