SQL Server轮询处理队列竞态问题：加多种锁后仍异常

我之前处理过好几个类似的多应用服务器、多进程任务分配的场景，结合SQL Server 2014的特性，咱们来拆解下你遇到的问题，以及可行的解决办法：

为什么现有锁提示还会出现竞态？ #

你提到已经加了ROWLOCK、READPAST、UPDLOCK，还结合了应用锁，但竞态依然存在，大概率是因为任务分配的逻辑不是原子操作——比如先执行SELECT查询待处理任务，再执行UPDATE标记为已分配，这两步之间有时间窗口，其他进程完全可以插队抢走同一条任务。另外，应用锁的使用如果没和事务绑定，或者隔离级别设置不对（比如开启了快照隔离），也会导致锁提示失效。

可行的解决方案 #

1. 用原子性UPDATE语句获取任务（核心方案） #

把“查询待处理任务”和“标记已分配”合并成一个原子的UPDATE操作，这样SQL Server会保证整个操作的排他性，彻底消除竞态窗口。示例代码如下：

-- 每个进程/服务器传入自己的标识，比如@ServerName
UPDATE TOP (1) TaskQueue
SET 
    AssignedServer = @ServerName,
    AssignedTime = GETDATE(),
    Status = 'Assigned'
OUTPUT inserted.* -- 返回被分配的任务信息给应用程序
WHERE Status = 'Pending'
ORDER BY TaskId -- 这里的排序可以调整，适配轮询逻辑
OPTION (ROWLOCK, READPAST, UPDLOCK)

• TOP (1)确保每次只获取一个任务
• OUTPUT子句直接返回被更新的任务数据，不需要额外查询
• 整个操作是原子性的，SQL Server会自动维护锁的排他性，其他进程的READPAST会跳过已被锁定的行

2. 实现严格的Round-Robin轮询分配 #

如果需要严格按轮询规则分配（比如服务器A、B、C依次轮流拿任务），可以通过窗口函数来给任务分配“轮询序号”，让每个服务器只获取对应自己序号的任务：

-- 假设总共有3台服务器，当前服务器的序号是@ServerIndex（0、1、2）
WITH RankedTasks AS (
    SELECT 
        *,
        -- 按任务ID排序，给每个任务分配轮询序号
        ROW_NUMBER() OVER (ORDER BY TaskId) % 3 AS ServerRank
    FROM TaskQueue
    WHERE Status = 'Pending'
)
UPDATE RankedTasks
SET 
    Status = 'Assigned',
    AssignedServer = @ServerName,
    AssignedTime = GETDATE()
OUTPUT inserted.*
WHERE ServerRank = @ServerIndex
OPTION (ROWLOCK, READPAST, UPDLOCK)

这样每台服务器只会拿到对应自己序号的任务，完美实现轮询分配，同时保持原子性。

3. 确保锁和事务的正确范围 #

• 所有任务分配的逻辑必须放在同一个事务内，避免锁提前释放
• 如果数据库开启了快照隔离，需要在执行任务分配语句前显式设置隔离级别：

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  

  因为快照隔离下，READPAST不会跳过锁定的行，而是读取版本化数据，这会导致锁提示失效。

4. 正确使用应用锁（备选方案） #

如果必须用应用锁，一定要和事务绑定，确保锁的生命周期和任务分配事务一致：

BEGIN TRANSACTION;

-- 获取数据库级的应用锁，锁定资源为TaskQueueLock
EXEC sp_getapplock 
    @Resource = 'TaskQueueLock', 
    @LockMode = 'Exclusive', 
    @LockOwner = 'Transaction';

-- 执行原子UPDATE获取任务（同方案1的代码）
UPDATE TOP (1) TaskQueue
SET AssignedServer = @ServerName, AssignedTime = GETDATE(), Status = 'Assigned'
OUTPUT inserted.*
WHERE Status = 'Pending'
ORDER BY TaskId
OPTION (ROWLOCK, READPAST, UPDLOCK);

-- 释放应用锁
EXEC sp_releaseapplock 
    @Resource = 'TaskQueueLock', 
    @LockOwner = 'Transaction';

COMMIT TRANSACTION;

注意：应用锁是数据库级别的，可能会影响并发性能，所以优先用原子UPDATE的方案。

总结 #

核心思路就是消除“查询-更新”的间隙，用原子操作保证任务分配的排他性，同时结合锁提示和正确的隔离级别，就能解决竞态条件问题。如果需要严格轮询，窗口函数是最优雅的实现方式。

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