一文搞懂: PostgreSQL的FOR UPDATE SKIP LOCKED

1. FOR UPDATE SKIP LOCKED 是什么？

从根本上说，FOR UPDATE SKIP LOCKED 是 PostgreSQL SELECT 语句中的一个行级锁（Row-Level Lock） 子句。它有两个关键部分：

• FOR UPDATE：这是一个标准的锁定子句，它的作用是锁定 SELECT 语句查询到的所有行。一旦某一行被一个事务锁定，其他任何试图锁定或修改（UPDATE/DELETE）该行的事务都必须等待，直到第一个事务 COMMIT 或 ROLLBACK 释放该锁。

• SKIP LOCKED：这是对 FOR UPDATE 行为的修改器（Modifier）。它的核心作用是改变事务在遇到“已被其他事务锁定”的行时的行为。默认情况下（仅使用 FOR UPDATE），事务会停下来等待锁释放。而加上 SKIP LOCKED 后，事务会立即跳过这些已被锁定的行，就好像它们不存在于查询结果中一样，然后继续处理查询范围内的其他行。

一句话总结：FOR UPDATE SKIP LOCKED 的作用是“查询并锁定符合条件的、且当前未被任何其他事务锁定的行，并立即忽略那些已经被锁定的行”。

2. 它解决了什么问题？

FOR UPDATE SKIP LOCKED 旨在解决高并发系统中因锁竞争（Lock Contention） 导致的性能瓶颈和系统吞吐量下降的问题。

想象一个没有 SKIP LOCKED 的经典任务队列场景：

1. 数据库中有一个 tasks 表，包含许多 status = 'pending' 的任务。

2. 进程 A 启动一个事务，执行 SELECT ... WHERE status = 'pending' ORDER BY created_at LIMIT 1 FOR UPDATE;。它成功锁定了 id=1 的任务并开始处理。

3. 几乎在同一时刻，进程 B 也执行了完全相同的查询。它也想获取最早的待处理任务，也就是 id=1。

4. 由于 id=1 的行已被进程 A 锁定，进程 B 的 SELECT 语句会被阻塞（Block），进入等待状态。

5. 同样，进程 C、进程 D 也都来获取任务，它们都会因为试图锁定 id=1 而被阻塞。

问题显而易见：尽管有大量的待处理任务和空闲的工作进程，但所有进程都被阻塞在获取同一个资源上，系统实际上变成了串行执行，并发处理能力大打折扣。

FOR UPDATE SKIP LOCKED 通过优雅地打破这种僵局来解决这个问题：

当进程 B 执行 SELECT ... FOR UPDATE SKIP LOCKED 时，它发现 id=1 的行已被锁定，于是它不会等待，而是立即跳过 id=1，继续查找下一个符合 status = 'pending' 条件且未被锁定的行（比如 id=2），然后锁定 id=2 并返回。同样，进程 C 会跳过 id=1 和 id=2，获取并锁定 id=3。

最终效果：多个工作进程可以真正地并行工作，各自从队列中领取不同的任务，从而极大地提高了整个系统的任务处理吞吐量。

3. 在实际中有什么应用？

最核心和最广泛的应用就是使用数据库实现高性能、高并发的任务/作业队列（Job Queue）。

典型应用：数据库任务队列

一个健壮的任务队列实现如下：

表结构:

CREATE TABLE job_queue (
    id BIGSERIAL PRIMARY KEY,
    payload JSONB NOT NULL,
    status TEXT NOT NULL DEFAULT 'queued', -- 'queued', 'processing', 'done', 'failed'
    priority INTEGER NOT NULL DEFAULT 0,
    retry_count INTEGER NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 为了高效查询，建立索引
CREATE INDEX idx_job_queue_fetch ON job_queue (priority DESC, created_at) WHERE status = 'queued';

工作进程（Worker）获取任务的逻辑:

-- Worker 会在一个循环中执行以下事务
BEGIN;

-- 原子性地获取一个任务
-- 1. 优先获取高优先级的
-- 2. 在相同优先级下，获取最早创建的
-- 3. 跳过任何已被其他 worker 锁定的任务
-- 4. 只获取一个任务来处理
SELECT id, payload
FROM job_queue
WHERE status = 'queued'
ORDER BY priority DESC, created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

-- 假设查询返回了 id=123 的任务
-- 如果没有任务返回，说明队列为空，可以等待一会再试

-- 将任务状态更新为 'processing'，防止其他逻辑（如监控）误判
UPDATE job_queue
SET status = 'processing', updated_at = NOW()
WHERE id = 123;

COMMIT;

-- 在事务外部，安全地执行任务（例如：发送邮件，处理数据）
-- ... processing payload ...

-- 任务完成后，更新最终状态
UPDATE job_queue SET status = 'done', updated_at = NOW() WHERE id = 123;

其他应用场景：

• 资源池管理：从一个包含可用资源（如优惠券码、游戏服务器实例、临时账号）的表中，让多个客户端无冲突地领取一个可用资源。

• 分布式锁服务：虽然有更专业的工具（如 ZooKeeper, etcd），但在某些场景下，可以利用 SKIP LOCKED 实现一个简单的、性能尚可的分布式锁。

• 数据批处理：多个进程分片处理一个大表中的数据，每个进程负责一个不重叠的数据子集。

4. 我想学习这块的知识

要系统地学习和掌握 FOR UPDATE SKIP LOCKED，建议遵循以下路径：

第一阶段：理解理论基础

1. ACID 和事务隔离级别：首先必须牢固掌握数据库事务的 ACID 属性（原子性、一致性、隔离性、持久性）。理解 PostgreSQL 的默认隔离级别——读已提交（Read Committed），以及它与可重复读（Repeatable Read）的区别。

2. PostgreSQL 锁机制：学习 PostgreSQL 中不同类型的锁（表级锁、行级锁、咨询锁等）以及它们的兼容性。重点理解行级排他锁（Row-Exclusive Lock），FOR UPDATE 获取的就是这类锁。

第二阶段：核心功能实践

1. 实践 FOR UPDATE：打开两个数据库客户端（psql），在客户端 A 中 BEGIN; SELECT ... FOR UPDATE; 锁定一行，但不要提交。然后在客户端 B 中尝试 UPDATE 或 SELECT ... FOR UPDATE 相同的行，亲身感受“阻塞等待”的效果。

2. 实践 SKIP LOCKED：重复上述实验，但在客户端 B 中使用 SELECT ... FOR UPDATE SKIP LOCKED，观察它如何立即跳过锁定的行并返回其他结果（或空结果）。

3. 实践 NOWAIT：学习 FOR UPDATE NOWAIT。它与 SKIP LOCKED 的区别在于，遇到锁定的行时，NOWAIT 会立即报错并回滚事务，而不是跳过。这适用于“要么立即拿到锁，要么就失败”的场景。

第三阶段：深入与对比

1. 与专业消息队列对比：

   • 优点：

     • 零额外依赖：如果你的项目已经在使用 PostgreSQL，那么无需引入和维护新的系统（如 RabbitMQ, Kafka）。

     • 事务性：可以利用数据库的强事务能力，将“出队”操作和业务数据更新放在同一个事务中，保证操作的原子性，这是许多外部消息队列难以做到的。

     • 数据一致性：任务数据和业务数据在同一个数据库中，易于查询、备份和保持一致。

   • 缺点：

     • 性能极限：在高吞吐量（每秒数万甚至数十万条消息）下，数据库轮询和锁的开销会成为瓶颈，性能不如专为消息传递设计的系统。

     • 功能有限：缺少高级路由（Fanout, Topic）、延迟消息、死信队列等复杂的消息中间件功能（虽然部分可以通过 SQL 模拟）。

     • 数据库负载：频繁的轮询会增加数据库的 CPU 和 I/O 负载。

结论：对于中低吞吐量、对事务性要求高、且希望简化技术栈的场景，使用 PostgreSQL 和 SKIP LOCKED 实现任务队列是一个非常出色和可靠的选择。对于需要极高吞吐量和复杂消息路由的场景，则应选择专业的队列系统。

对 PostgreSQL 中 FOR UPDATE SKIP LOCKED 的全面分析：从并发原语到架构模式

第 1 节：非阻塞行获取的机制

本节旨在奠定 PostgreSQL 行级锁定的基本原理，明确 SKIP LOCKED 旨在解决的问题，并分析其底层的性能特征。

1.1 基础：理解 SELECT FOR UPDATE 与锁竞争

SELECT... FOR UPDATE 是 PostgreSQL 中一种实现悲观锁定的核心机制。其核心概念在于，该命令会对查询返回的所有行获取一个排他性的 LockTupleExclusive 锁 。此锁的效力是阻止任何其他事务对这些行进行修改（  

UPDATE）、删除（DELETE）或获取另一排他锁，直到持有该锁的当前事务提交（COMMIT）或回滚（ROLLBACK）为止 。  

这种机制的根本目的在于防止在经典的“读取-修改-写入”周期中发生“丢失更新”的并发问题，从而保障数据完整性 。然而，其默认行为也带来了并发系统中的一个核心挑战：阻塞。当一个事务尝试访问一个已被  

FOR UPDATE 锁定的行时，它不会立即失败或跳过，而是会进入等待状态，直到该锁被释放 。在具有多个并发工作进程（worker）的高并发系统中，这种行为会导致工作进程序列化，形成一个等待锁释放的队列，从而产生性能瓶颈 。  

1.2 SKIP LOCKED 范式：一种非阻塞的并发处理方法

SKIP LOCKED 子句于 PostgreSQL 9.5 版本中引入，它从根本上改变了 FOR UPDATE 的阻塞行为 。其核心功能是，当查询遇到一个已被其他事务锁定的行时，它不会等待，而是简单地忽略（跳过）该行，并继续寻找下一个符合  

WHERE 条件且未被锁定的可用行 。  

这种非阻塞的行为模式与另一种非阻塞选项 NOWAIT 形成了鲜明对比。NOWAIT 在遇到锁定时，不会跳过，而是立即返回一个错误 。这使得  

NOWAIT 适用于需要快速失败（fail-fast）的应用场景，而 SKIP LOCKED 则天然适用于工作分发场景，尤其是在实现高吞吐量的并行作业队列时。它允许多个工作进程从一个共享的表中声明不同的作业，而无需相互竞争和等待 。  

这种机制的价值不仅仅在于“避免等待”，更深层次的意义在于它将查询的语义目的从确定性的数据检索（“给我这些特定的行”）转变为机会性的工作获取（“给我任意 N 个符合条件且可用的行”）。这种思维框架的转变是理解其在队列系统中强大能力的关键。在一个传统的 OLTP 场景中，一个查询返回不一致的数据视图通常被视为一个缺陷。然而，在作业队列的上下文中，多个工作进程并不需要对所有可用作业的集合达成一致的视图；它们只需要获取一个唯一的、不重叠的工作子集。因此，SKIP LOCKED 通过利用这种“不一致视图”的行为，将数据库从一个单纯的状态存储转变为一个并发的工作分发器，从而催生了一种新的应用模式。

1.3 底层原理：元组级锁定的性能影响

行级锁定并非没有成本。当执行 SELECT FOR UPDATE 时，PostgreSQL 需要执行两个关键操作：首先，在磁盘上的元组头部（tuple header）写入事务标识符（xmin/xmax）以标记该行被锁定；其次，在共享内存的锁表（可通过 pg_locks 视图查看）中注册一个条目 。这两个操作意味着每次行锁定都会带来磁盘 I/O 和内存的双重开销。  

更重要的是，这种锁定机制对查询计划（query plan）有深远影响。为了检查一个行是否被锁定，数据库引擎必须从表堆（table heap）中读取元组头信息。这个要求使得高效的“仅索引扫描”（Index Only Scan）变得不可能，因为仅索引扫描的优势恰恰在于它能从索引中获取所有需要的数据，而无需访问表本身 。因此，带有  

FOR UPDATE 的查询计划中会包含一个 LockRows 操作节点，强制引擎执行两次读取：一次从索引读取，一次从表堆读取，这无疑会降低查询性能。

从设计上讲，SKIP LOCKED 提供了一个故意不一致的数据视图 。这对于队列类应用是完全可以接受甚至是理想的，因为其目标是高效地分发工作，而非提供一个关于所有可用作业的精确快照。  

表 1：锁定行为比较 (FOR UPDATE, NOWAIT, SKIP LOCKED)

为了清晰地展示这些锁定子句之间的差异，下表总结了它们的核心行为和适用场景。

锁定子句	遇到锁定行时的行为	主要适用场景	对吞吐量的影响
FOR UPDATE	阻塞并等待锁释放	传统的“读取-修改-写入”周期，需要强一致性以防止丢失更新 。	序列化访问，在高并发下显著降低吞吐量。
FOR UPDATE NOWAIT	不等待，立即返回错误	需要快速失败（fail-fast）的场景，应用程序不能承受等待延迟 。	避免阻塞，但需要应用层处理错误和重试逻辑。
FOR UPDATE SKIP LOCKED	不等待，直接跳过锁定的行，继续查找下一个可用行	高并发的作业队列和任务分发系统，允许多个工作进程并行处理 。	显著提高并发吞吐量，因为工作进程之间不会相互阻塞。

第 2 节：首要优势：事务一致的作业队列

使用 FOR UPDATE SKIP LOCKED 的最大、最显著的优势在于，它能够利用数据库原生的事务保证，构建出架构简单且数据一致性强的系统。

2.1 原子性的力量：统一作业出队与业务逻辑

PostgreSQL 事务具备原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），即 ACID 特性 。包裹在  

BEGIN 和 COMMIT 块内的所有 SQL 语句被视为一个单一的、不可分割的工作单元 。  

这种原子性保证在实现作业队列时显得尤为强大。考虑一个典型的场景：一个工作进程需要处理一个“发送欢迎邮件”的作业。这个过程涉及多个数据库操作，可以被封装在单个事务中：

BEGIN;

-- 1. 从作业队列中获取一个待处理的作业，并将其锁定
SELECT * FROM jobs WHERE status = 'pending' AND job_type = 'welcome_email' ORDER BY created_at LIMIT 1 FOR UPDATE SKIP LOCKED;
-- 假设获取到 job_id = 123, user_id = 456

-- 2. 执行与作业相关的业务逻辑，更新应用状态
UPDATE users SET welcome_email_sent = TRUE WHERE id = 456;

-- 3. 将作业标记为完成
UPDATE jobs SET status = 'completed' WHERE id = 123;

COMMIT;

在这个事务中，作业的出队（通过 SELECT... FOR UPDATE 锁定）和相关的业务状态更新（UPDATE users）以及作业本身的状态更新（UPDATE jobs）被绑定在一起。PostgreSQL 的事务机制确保了这三个操作要么全部成功，要么全部失败 。如果中间的  

UPDATE users 操作因任何原因失败（例如，违反了某个约束），整个事务将自动回滚。事务回滚后，对 jobs 表的行锁被释放，其 status 字段也未被改变，这意味着该作业会“神奇地”重新出现在队列中，可供其他工作进程处理。这种机制从根本上杜绝了作业已处理但业务状态未更新，或业务状态已更新但作业未被标记为完成的数据不一致状态 。  

2.2 架构的简化：消除“双写”问题与外部依赖

当系统采用外部消息队列（如 RabbitMQ 或 Kafka）时，一个常见且棘手的分布式系统问题便会浮现——“双写问题”（Dual Write Problem）。在这种架构中，应用需要执行两个独立的操作：首先，在主数据库中更新状态（例如，将订单状态更新为“已支付”）；其次，向消息队列发布一个事件（例如，“订单支付成功”事件）。由于这两个操作分属不同的系统，它们无法被一个原生的事务包裹。如果其中一个操作成功而另一个失败（例如，数据库事务提交成功，但向 Kafka 发布消息时网络中断），系统就会陷入不一致的状态 。  

解决双写问题通常需要引入复杂的架构模式，如“事务性发件箱”（Transactional Outbox）或“两阶段提交”（Two-Phase Commit, 2PC）。这些模式虽然有效，但极大地增加了系统的架构复杂性和运维成本。  

相比之下，将 PostgreSQL 本身用作作业队列则巧妙地规避了整个问题。因为“作业”本身就是数据库中的一行数据，业务状态和队列状态位于同一个事务边界之内。作业处理与业务逻辑的更新可以通过一个标准的本地数据库事务实现原子性 。这种做法极大地简化了系统架构，将一个复杂的分布式一致性问题降级为一个已解决的、易于理解的本地数据库事务问题 。  

此外，这种方法还显著降低了运维开销。它避免了在技术栈中引入一个全新的组件，无需再部署、管理、监控和维护一个独立的、高可用的消息中间件集群，从而减少了系统的“活动部件”和潜在的故障点 。  

2.3 实现高吞吐量：并行工作处理的实践演示

SKIP LOCKED 的非阻塞特性是实现高吞吐量的关键。多个工作进程可以并行地向数据库请求作业，而不会相互干扰。

设想一个拥有多个工作进程的系统，每个进程都执行以下查询：

SELECT id, payload FROM jobs WHERE status = 'pending' ORDER BY priority DESC, created_at ASC LIMIT 10 FOR UPDATE SKIP LOCKED;

当第一个工作进程（Worker 1）执行此查询时，它会锁定最优先的 10 个作业。几乎在同一时间，第二个工作进程（Worker 2）也执行相同的查询。由于前 10 个作业已被 Worker 1 锁定，Worker 2 的查询会利用 SKIP LOCKED 的特性跳过这些行，并锁定接下来可用的 10 个作业。以此类推，每个工作进程都能高效地获取一批唯一的工作任务，实现了真正的并行处理 。这种模式允许系统通过简单地增加工作进程数量来进行水平扩展，从而提升整体的处理能力（当然，这种扩展并非无限制，其瓶颈将在下一节讨论）。  

第 3 节：关键缺点与操作陷阱

尽管 FOR UPDATE SKIP LOCKED 带来了显著优势，但它并非万能的。在特定条件下，它会暴露出严重的性能和功能限制。本节将深入剖析其缺点和潜在的操作陷阱。

3.1 性能天花板：分析可伸缩性极限与竞争崩溃

SKIP LOCKED 的核心在于避免等待，但这并不意味着跳过锁定的行是没有代价的。数据库引擎仍然需要扫描并检查那些已被其他事务锁定的行的锁定状态。当并发工作进程的数量和被锁定的行数变得非常庞大时，寻找一个未锁定行的过程本身就会变得越来越昂贵 。  

随着锁竞争的加剧，查询性能会开始显著下降。由于引擎需要跳过大量的锁定行，索引的有效性会降低，查询计划可能退化为效率低下的全表扫描（SEQSCAN）。在极端负载下——例如，数百个工作进程同时竞争作业——系统可能会遭遇“竞争崩溃”（Contention Collapse）。在这种状态下，数据库 CPU 使用率飙升至 100%，而查询响应时间从毫秒级恶化到分钟级，因为工作进程几乎所有的时间都消耗在遍历已被锁定的行上 。  

这种性能退化并非线性，而是呈现出悬崖式的下降。有报告指出，当并发连接数超过某个阈值（例如 128 个）时，系统性能会急剧恶化，几乎陷入停滞 。主要的缓解措施是限制每个事务锁定的行数（通过  

LIMIT 子句）以及控制并发工作进程的总数 。  

3.2 排序困境：队头阻塞与严格 FIFO 的牺牲

在许多系统中，先进先出（First-In, First-Out, FIFO）是一个重要的业务需求。然而，SKIP LOCKED 与严格的 FIFO 排序存在根本性的冲突。这种冲突体现为一种被称为“队头阻塞”（Head-of-Line Blocking）的现象 。  

在一个旨在实现 FIFO 的 PostgreSQL 队列中，工作进程通常会使用 ORDER BY created_at ASC... FOR UPDATE SKIP LOCKED 来获取最旧的待处理作业。问题在于，如果第一个工作进程（Worker 1）成功锁定了最旧的作业（队头元素），但该作业的处理时间非常长（例如，一个复杂的报表生成任务），那么会发生以下情况：所有其他工作进程在查询时，会发现队头作业已被锁定，于是它们会利用 SKIP LOCKED 的特性跳过这个作业，转而处理队列中更新的、可用的作业 。  

这种行为的结果是，队列中较新的作业被优先处理，而最旧的作业却因为其处理时间过长而被“搁置”，从而完全破坏了严格的 FIFO 顺序 。这并非一个可以修复的“缺陷”，而是一个固有的设计权衡。  

SKIP LOCKED 的设计目标是最大化并发度和整体吞吐量，这与保证严格顺序处理所需的序列化操作是天然对立的 。如果业务场景对严格的作业处理顺序有硬性要求，那么使用  

SKIP LOCKED 搭配多个工作进程的模式是完全不合适的。

3.3 分区悖论：探究 tuple already moved 异常

对于大型作业队列，一个常见的数据库管理策略是使用列表分区（List Partitioning），通常基于作业的 status 列（例如，为 pending、processing、completed 等状态创建不同的分区）。当一个作业被处理时，一个 UPDATE 语句会改变其状态，这会导致该行从一个分区“移动”到另一个分区 。  

然而，当在高并发环境下对这样的分区表使用 FOR UPDATE SKIP LOCKED 时，事务会频繁地因一个特定错误而失败：ERROR: tuple to be locked was already moved to another partition due to concurrent update（错误：待锁定的元组因并发更新已被移动到另一个分区）。  

这个错误的根源在于一个微妙的竞争条件。假设工作进程 A 的事务开始，并在 pending 分区中“看到”了一个符合条件的元组。但在进程 A 能够对该元组施加锁之前，工作进程 B 抢先一步锁定了该元组，执行了 UPDATE 操作并提交了事务，导致该元组被移动到了 completed 分区。此时，当进程 A 尝试去锁定它最初看到的那个元组时，它发现在原来的位置上已经找不到该元组了。PostgreSQL 的 SKIP LOCKED 逻辑并未将这种情况解释为一个可以安全跳过的锁定，而是将其视为一个不可恢复的状态错误，最终导致了事务的序列化失败 。  

这一现象揭示了基于分区进行状态管理的模式与 SKIP LOCKED 并发模型之间存在严重的兼容性问题。它迫使开发者要么放弃使用分区来管理队列，要么在应用层实现复杂的错误捕获和重试逻辑，从而增加了系统的复杂性 。  

3.4 “反模式”之辩：何时数据库队列是错误的选择？

长期以来，将数据库用作队列被许多人视为一种“反模式”（anti-pattern）。反对者的主要论点包括：  

1. 轮询开销（Polling Overhead）：工作进程需要不断地向数据库发出查询以检查新作业，这种持续的轮询会对数据库造成不小的压力，尤其是在作业稀疏的时期 。  

2. 资源竞争（Resource Contention）：队列操作（高频率的 INSERT、UPDATE、DELETE）会与应用的核心 OLTP 工作负载争夺 CPU、内存和 I/O 资源，可能影响应用的整体性能 。  

3. 表膨胀（Table Bloat）：队列中作业的频繁增删改查会导致表中出现大量“死元组”，造成表和索引的物理体积不断膨胀，这需要配置积极的 VACUUM策略来回收空间，增加了数据库维护的复杂性 。  

4. 高级功能缺失（Lack of Advanced Features）：专用的消息中间件（如 RabbitMQ）提供了许多开箱即用的高级功能，例如复杂的消息路由、扇出（fanout）、死信交换（dead-letter exchange）等。而在 PostgreSQL 队列中，这些功能都需要开发者手动实现 。  

然而，支持者认为，随着 PostgreSQL 自身的发展（特别是 SKIP LOCKED 的引入），这种“反模式”的论点已经过时 。对于许多工作负载而言，PostgreSQL 队列提供的事务完整性和架构简单性所带来的好处，远超过其缺点 。最终，这并非一个绝对的对错问题，而是一个依赖于具体应用场景和需求的权衡。  

这些缺点并非孤立存在，而是构成了一个相互关联的权衡体系。对非阻塞高吞吐量的追求（SKIP LOCKED 的核心优势）直接导致了 FIFO 排序的丧失。实现这一点的底层机制（行级锁）又带来了性能开销，并设定了可伸缩性的上限。而试图通过分区来解决大规模表管理问题的策略，又与锁定机制本身发生了冲突。这揭示了 FOR UPDATE SKIP LOCKED 并非一个万能的解决方案，而是一个具有明确但狭窄适用范围的专用工具。架构师必须接受其所有权衡，而不能只选择其优点。

第 4 节：构建弹性系统：最佳实践与缓解模式

为了构建一个基于 SKIP LOCKED 的、既健壮又高效的作业队列系统，必须采用一系列的设计模式和最佳实践来应对上一节中识别出的挑战。一个生产级的 PostgreSQL 队列并非由单一查询构成，而是一个复合设计模式的体现。

4.1 高效地发现工作：优化出队操作

为解决轮询带来的性能问题和扫描大型表的开销，可以组合使用多种 PostgreSQL 特性。

4.1.1 使用部分索引（Partial Indexes）

当工作进程查询 status = 'pending' 的作业时，如果 pending 状态的作业只占表的一小部分，那么全表索引的效率会很低。此时，可以创建一个部分索引，它只包含满足特定条件的行。

CREATE INDEX idx_jobs_pending ON jobs (priority DESC, created_at ASC) WHERE status = 'pending';

这个索引只针对状态为 pending 的作业创建，因此其体积远小于全表索引。工作进程的查询可以高效地利用这个小而精的索引来快速定位可用作业，从而显著提升查询性能并避免全表扫描，尤其是在作业表非常庞大时 。  

4.1.2 采用 LISTEN/NOTIFY 模式减少轮询

为了避免工作进程在没有新作业时进行空轮询，可以利用 PostgreSQL 的内置发布/订阅机制 LISTEN/NOTIFY 。  

实现方式如下：

1. 工作进程监听：每个工作进程启动时，在数据库连接上执行 LISTEN new_jobs;，监听一个名为 new_jobs 的通道。

2. 触发器通知：在 jobs 表上创建一个触发器，当有新行 INSERT 时，该触发器执行 pg_notify('new_jobs', job_id::text);，向通道发送通知。

3. 事件驱动处理：工作进程的监听连接会阻塞等待通知。一旦收到通知，它就会被唤醒，并立即执行 SELECT... FOR UPDATE SKIP LOCKED 查询来获取新作业。

这种模式将轮询从“拉”模型转变为“推”模型，极大地减少了数据库的空闲查询负载，并降低了从作业入队到开始处理的延迟 。  

然而，LISTEN/NOTIFY 存在局限性。它的通知传递保证是“至多一次”（at most once），如果监听的客户端在通知发送时断开连接，它将永久错过该通知 。此外，通知的负载（payload）大小有限制（8000 字节）。因此，  

LISTEN/NOTIFY 应被用作触发即时工作的优化手段，而不是一个完全可靠的消息传递机制。系统仍需保留一个较低频率的周期性轮询作为后备（fallback），以确保不会遗漏任何因连接中断而错过的作业 。  

4.2 构建健壮的工作进程：实现重试与“可见性超时”以处理僵尸作业

4.2.1 失败重试机制

工作进程在处理作业时可能会遇到瞬时故障（如外部 API 超时、网络波动）。为了不丢失这些作业，需要一个重试机制。一个简单的实现是在 jobs 表中增加一个 retry_count 列。

• 当工作进程获取一个作业时，可以立即在事务中将 retry_count 加一。

• 出队查询应包含 WHERE retry_count < :max_retries 条件，以避免无限重试 。  

• 如果作业处理成功，则将其状态更新为 completed。如果失败，工作进程只需回滚事务，作业就会被其他进程重新拾取。

• 当一个作业的 retry_count 达到最大限制后，应将其移入一个“死信表”（dead-letter table），供开发人员进行手动分析和处理 。  

4.2.2 处理“僵尸作业”：可见性超时模式

一个更危险的情况是工作进程在锁定一个作业后自身崩溃。该进程持有的事务最终会超时并由 PostgreSQL 清理，行锁也会被释放。但如果工作进程在崩溃前已经将作业状态更新为 processing 并提交了一个独立的事务（这是一个不推荐的坏实践），或者在单次长事务中崩溃，那么该作业可能会永远停留在 processing 状态，成为一个无法被其他工作进程拾取的“僵尸作业”。

“可见性超时”（Visibility Timeout）模式是解决此问题的经典方案。其实现方式如下：

1. 在 jobs 表中增加一个 visible_at 时间戳列。

2. 当一个工作进程锁定并开始处理一个作业时，它在事务中将该作业的 visible_at 更新为一个未来的时间点，例如 NOW() + '5 minutes'::interval。

3. 工作进程的出队查询逻辑需要相应调整，以拾取那些“本应完成但超时”的作业：

SELECT id FROM jobs
WHERE
  (status = 'pending' OR (status = 'processing' AND visible_at <= NOW()))
  AND retry_count < 5
ORDER BY created_at
LIMIT 1
FOR UPDATE SKIP LOCKED;

通过这种方式，任何因工作进程崩溃而卡在 processing 状态超过 5 分钟的作业，都会被其他健康的工作进程自动“回收”并重新尝试处理。这个模式无需外部的监控进程或心跳机制，仅依靠数据库自身的状态就能实现强大的容错能力 。  

4.3 关于锁粒度的考量：FOR NO KEY UPDATE 与咨询锁

4.3.1 FOR NO KEY UPDATE 的使用

如果作业处理逻辑保证不会更新被索引的键（主键或唯一键），那么使用 FOR NO KEY UPDATE 会比 FOR UPDATE 更好。FOR NO KEY UPDATE 获取的锁级别较低，它不会与 FOR KEY SHARE 锁（通常由外键约束隐式获取）冲突。在具有复杂外键关系的数据库模式中，这可以减少不必要的锁竞争，从而提高并发性 。  

4.3.2 咨询锁（Advisory Locks）作为替代方案

PostgreSQL 还提供了咨询锁，这是一种与表或行无关、由应用程序自定义的锁。工作进程可以尝试获取一个基于作业 ID（一个整数）的咨询锁，例如 pg_try_advisory_xact_lock(job_id)。

优势：

• 与事务生命周期解耦：咨询锁可以是会话级别（session-level）的，这意味着它们可以在事务提交后继续持有，直到会话结束或被显式释放。这对于处理时间非常长的作业特别有用，可以避免持有长事务（long-lived transaction），因为长事务会阻止 VACUUM 清理，导致表膨胀 。  

• 不阻塞数据写入：咨询锁不直接锁定物理行，因此它不会阻止其他事务更新被“逻辑锁定”的作业行的数据 。  

• 锁定不存在的对象：可以对一个尚不存在于数据库中的概念（例如，一个即将被创建的用户 ID）进行锁定，以防止并发创建冲突 。  

劣势：

• 应用逻辑更复杂：锁的管理完全由应用程序负责，更容易出错。

• 与连接池不兼容：在事务池模式下（如 PgBouncer 的 transaction pooling mode），客户端的多个事务可能在不同的后端数据库连接上执行。由于会话级咨询锁与后端连接绑定，这会导致锁的逻辑失效 。  

• 与 LIMIT 的交互问题：当在查询中使用咨询锁函数时，LIMIT 子句不保证在锁定函数执行之前应用，这可能导致获取到预期之外的锁 。  

结论：对于大多数标准的作业队列场景，FOR UPDATE SKIP LOCKED 更简单、更直观，因为它将锁与数据本身紧密绑定。咨询锁则为长耗时作业等特殊场景提供了更大的灵活性，但代价是增加了应用程序的复杂性和对基础设施的特定要求。

第 5 节：架构师指南：PostgreSQL 队列与专用消息中间件的对比

本节将进行高层次的比较分析，帮助架构师在 PostgreSQL 队列和专用消息中间件（如 RabbitMQ、Kafka）之间做出明智的技术选型。这个决策超越了 SKIP LOCKED 机制本身，触及了更广泛的系统架构哲学。

5.1 功能特性对比：专用中间件的“开箱即用”优势

PostgreSQL 队列本质上是一种“自己动手”（DIY）的方案，而专用的消息中间件则提供了丰富且成熟的功能集。

特性	PostgreSQL 队列	RabbitMQ	Apache Kafka
与应用数据库的事务原子性	原生支持：作业状态与业务数据在同一事务内，保证强一致性 。	不支持：需要复杂的“事务性发件箱”模式来解决双写问题 。	不支持：同样需要“事务性发件箱”或类似的模式 。
死信队列 (DLQ)	需手动实现：例如，通过 retry_count 和一个单独的 dead_jobs 表 。	原生支持：核心功能，可自动路由无法处理或过期的消息 。	需通过应用逻辑或 Kafka Streams/Connect 实现类似功能。
消息路由/扇出 (Fanout)	需手动实现：例如，通过触发器将一条消息复制到多个表中 。	原生支持：通过交换机（Exchange）类型（Direct, Topic, Fanout, Headers）实现灵活、强大的路由逻辑 。	通过消费者组（Consumer Groups）实现广播（扇出）模式。
消息重放 (Replay)	可实现：通过查询历史作业表并重新插入来实现。	传统队列不支持，但 RabbitMQ Streams 支持非破坏性消费和重放 。	核心特性：基于持久化的、不可变的日志，消费者可以从任意偏移量开始重放消息 。
典型吞吐量	中低（数千条/秒）	中高	极高（数十万至数百万条/秒）
运维复杂度	低：复用现有数据库，无需额外组件 。	中：需要部署和维护一个独立的、高可用的 RabbitMQ 集群 。	高：需要管理 Kafka 集群和 ZooKeeper/KRaft，运维复杂 。

这种差异体现了“智能消费者 vs. 智能代理”的范式分野 。RabbitMQ 是一个“复杂代理，简单消费者”的系统，它承担了大部分高级消息处理逻辑。而 PostgreSQL 队列则是一个“简单代理，智能消费者”的系统，它将实现重试、死信、路由等功能的责任转移给了应用程序开发者。  

5.2 规模化性能：吞吐量基准与延迟考量

• 中低负载：对于大多数典型应用（例如，每秒处理少于 1000 个作业），一个经过良好优化的 PostgreSQL 队列通常是“足够好”的选择。它的运维简单性在这种场景下是巨大的优势 。已有基准测试表明，基于咨询锁的 PostgreSQL 队列可以达到每秒数千个作业的处理能力 。  

• 高吞吐量与流处理：专用系统，特别是 Kafka，被设计用于处理极高的吞吐量（每秒数百万条消息）和大规模数据流的场景。它的持久化日志架构使其成为事件溯源、日志聚合和实时数据管道的理想选择，这些场景远超出了关系型数据库的优化范畴 。  

• 延迟：作为内存数据存储，Redis 在用作队列时通常能提供比基于磁盘的 PostgreSQL 更低的延迟 。然而，基准测试结果可能具有误导性，它高度依赖于具体的工作负载、硬件配置和网络条件 。对于许多应用来说，PostgreSQL 提供的毫秒级延迟已经完全足够。  

5.3 决策框架：如何选择合适的技术

最终的技术选型应基于项目的具体需求。下表提供了一个决策框架，帮助架构师根据关键需求进行权衡。

如果您的首要需求是...	那么优先考虑...	因为...
与应用数据的绝对事务一致性	PostgreSQL 队列	它能在一个原子事务中完成业务数据更新和作业出队，从根本上消除了分布式系统中的双写问题，极大地简化了架构 。
极高的吞吐量或事件流处理	Apache Kafka	Kafka 是为持久化、高吞吐、可重放的事件流而设计的，其性能和架构远超关系型数据库在此领域的表现 。
复杂的消息路由和灵活的消息模式	RabbitMQ	RabbitMQ 提供了强大的交换机（Exchange）机制，支持开箱即用的复杂路由、扇出、主题订阅等模式，简化了消费者端的逻辑 。
最大化架构简单性和最小化运维成本（中等吞吐量）	PostgreSQL 队列	它复用了您已有的核心数据库设施，无需引入、学习和维护一个新的分布式系统，对于大多数标准后台作业处理场景而言，这是最务实的选择 。

这个选择过程揭示了一个更深层次的考量：这并非一个纯粹的技术决策，而是一个关于组织选择在何处投入其“复杂性预算”的战略决策。选择 PostgreSQL 队列，意味着接受在应用/消费者逻辑中处理复杂性（自己实现重试、死信队列等）的代价，以换取基础设施的简单性。反之，选择专用的消息中间件，意味着接受在基础设施中处理复杂性（管理一个新系统、解决双写问题）的代价，以换取应用/消费者逻辑的简单性。团队必须评估自身是更擅长处理应用层面的复杂性，还是基础设施层面的复杂性。

第 6 节：结论与战略建议

本报告对 PostgreSQL 中的 FOR UPDATE SKIP LOCKED 机制进行了深入、全面的分析。综合各项优缺点、实践模式和架构考量，可以得出以下结论和建议。

6.1 FOR UPDATE SKIP LOCKED 的权衡综合

FOR UPDATE SKIP LOCKED 是一个强大但专用的并发控制原语。它的核心价值在于将一个传统的阻塞式锁定操作转变为非阻塞式的工作获取机制，从而为在关系型数据库内构建高效的作业队列提供了可能。

其核心优势在于：

• 事务原子性：能够将作业处理与业务逻辑更新无缝地整合在单个 ACID 事务中，从根本上消除了分布式系统中的“双写”难题，保证了数据的强一致性。

• 高并发性：允许多个工作进程并行地从队列中获取作业而互不阻塞，显著提高了在合适工作负载下的系统总吞吐量。

• 架构简单性：通过复用现有的 PostgreSQL 数据库，避免了引入、部署和维护一个独立的、复杂的外部消息中间件系统，降低了运维成本和系统复杂性。

然而，这些优势伴随着一系列严峻的、不可忽视的劣势：

• 性能天花板：在高并发和高锁竞争下，跳过大量已锁定行的开销会急剧增加，导致性能断崖式下跌，甚至出现“竞争崩溃”现象。

• 牺牲严格排序：为了实现高并发，该机制天然地会导致“队头阻塞”，从而破坏严格的先进先出（FIFO）顺序。它为吞吐量牺牲了顺序性。

• 功能局限性：与分区等高级数据库特性存在兼容性问题，并且缺乏专用消息系统所提供的丰富功能（如死信队列、复杂路由），这些都需要在应用层手动实现。

6.2 实施与架构战略的最终建议

基于以上分析，为技术决策者提供以下战略建议：

何时应优先选择 FOR UPDATE SKIP LOCKED？

• 当与主数据库的事务一致性是首要且不可妥协的需求时。

• 当系统对后台作业的吞吐量要求处于中低水平（例如，每秒数百到数千个作业），且可以通过水平扩展工作进程来满足。

• 当严格的 FIFO 处理顺序并非业务的硬性要求时。

• 当团队希望最大程度地简化系统架构，降低运维负担，并希望利用现有的 PostgreSQL 专业知识时。

对于向一个已有的、基于 PostgreSQL 的应用中添加后台作业处理功能，FOR UPDATE SKIP LOCKED 是一个卓越且务实的默认起点 。  

何时应避免使用 FOR UPDATE SKIP LOCKED 并选择专用系统？

• 当应用场景是大规模事件流、日志聚合或需要极高吞吐量（每秒数万至数百万消息）时，应选择 Apache Kafka 。  

• 当业务逻辑需要严格的 FIFO 排序时，使用 SKIP LOCKED 搭配多个工作进程的模式是错误的。

• 当需要复杂的、开箱即用的消息路由、扇出或主题分发能力时，应选择 RabbitMQ 。  

• 当预计队列的并发竞争会非常激烈，可能触及 PostgreSQL 的性能天花板时。

实施清单 如果决定采用 FOR UPDATE SKIP LOCKED 方案，建议遵循以下清单来构建一个生产级的系统：

1. 确认排序需求：明确并记录业务可以接受非严格的 FIFO 排序。

2. 实施弹性模式：不要只使用单一的 SELECT 查询。必须实现完整的弹性模式，包括：

   • 使用部分索引优化出队查询性能 。  

   • 实现可见性超时模式（例如，使用 visible_at 列）来自动处理僵尸作业 。  

   • 在工作进程中内置重试逻辑和死信处理机制 。  

3. 优化轮询策略：采用 LISTEN/NOTIFY 作为即时触发机制，但保留一个低频的轮询作为可靠性后备 。  

4. 进行负载测试：在部署前，通过模拟真实的并发负载进行基准测试，以了解系统的性能拐点和资源瓶颈。

5. 谨慎使用分区：避免使用基于 status 的列表分区，如果 UPDATE 操作会导致行在分区之间移动，因为这在高并发下会引发 tuple already moved 错误 。  

6. 预留架构演进空间：在应用层将队列逻辑进行抽象封装。这可以在未来当系统规模超出 PostgreSQL 队列能力时，以最小的代码重构成本，平滑地迁移到专用的消息中间件 。  

SKIP LOCKED 不能直接用在 UPDATE 语句的语法中，但可以通过将 SELECT... FOR UPDATE SKIP LOCKED 作为子查询或在 CTE (Common Table Expression) 中，来驱动 UPDATE 操作，从而实现“更新未被锁定的行”这一效果。

FOR UPDATE SKIP LOCKED 是 SELECT 语句独有的锁定子句 。你不能写出像  

UPDATE my_table SET... SKIP LOCKED 这样的语句，这在语法上是不成立的。

然而，在实际应用中，我们几乎总是将 SELECT... FOR UPDATE SKIP LOCKED 和 UPDATE 结合起来，以实现原子的“出队”操作。这通常通过以下几种常见的模式实现：

模式一：在 WHERE IN 子句中使用子查询

这是最常见和直观的模式。它在一个语句中原子性地完成“查找、锁定、更新”三个步骤。

UPDATE tasks
SET status = 'processing', worker_id = 123
WHERE id IN (
    SELECT id
    FROM tasks
    WHERE status = 'pending'
    ORDER BY created_at
    FOR UPDATE SKIP LOCKED
    LIMIT 10
)
RETURNING *;

工作原理分析 ：  

1. 子查询执行：PostgreSQL 首先执行 WHERE IN 中的子查询。

2. 查找并锁定：该子查询会查找最多10个 status 为 'pending' 的任务，并使用 FOR UPDATE SKIP LOCKED 锁定它们。任何已经被其他事务锁定的行都会被跳过。

3. 返回ID：子查询将成功锁定行的 id 返回给外部的 UPDATE 语句。

4. 执行更新：外部的 UPDATE 语句现在只对这些已经被当前事务锁定的行进行更新。因为这些行已经被锁定，所以这个操作是完全安全的，不会有竞态条件。

5. 返回结果：RETURNING * 子句会将更新后的行返回给客户端，这样工作进程就知道自己成功获取了哪些任务。

模式二：使用通用表表达式 (CTE)

使用 WITH 子句（CTE）可以使查询逻辑更清晰，尤其是在逻辑变得复杂时。

WITH locked_tasks AS (
    SELECT id
    FROM tasks
    WHERE status = 'pending'
    ORDER BY created_at
    FOR UPDATE SKIP LOCKED
    LIMIT 10
)
UPDATE tasks
SET status = 'processing', worker_id = 123
FROM locked_tasks
WHERE tasks.id = locked_tasks.id
RETURNING tasks.*;

这种写法的效果与第一种模式完全相同，但可读性更强 。它明确地将“锁定行”的步骤分离到 CTE 中，然后在主  

UPDATE 语句中引用这些被锁定的行。

总结

所以，虽然 SKIP LOCKED 在语法上属于 SELECT，但通过巧妙地将其嵌入到 UPDATE 语句中，我们实现了 “只更新那些我们能成功锁定的行” 的强大功能。这正是 FOR UPDATE SKIP LOCKED 在构建高性能数据库任务队列时如此关键和高效的原因。