MS SQL Server - 具有队列逻辑的表 - 如何确定并行任务不会检索相同的 ID？

Question

我有一个表，sys_QueueJob存储队列逻辑数据。

我认为更新并返回就足够了...但是，现在我不确定这是否 100% 安全。

我如何确定无论有多少并行请求都不会返回相同的 ID？

UPDATE sys_QueueJob
SET ExecutionStartedOn = GETDATE()
OUTPUT DELETED.Id as Result
WHERE Id = (select top 1 x.Id
            from sys_QueueJob x with (rowlock, updlock, readpast)
                        where x.ExecutionFinishedOn is null
                            AND (
                                x.ExecutionStartedOn is null
                                OR x.ExecutionStartedOn < DATEADD(HOUR, -1, GETDATE())
                               )
                        order by x.CreatedOn asc)

Answer 1

排队

就像我在这篇文章中讨论的那样，处理队列的可靠方法是使用如下查询：

WITH 
    q AS
(
    SELECT TOP (1) 
        x.* 
    FROM sys_QueueJob x WITH (ROWLOCK, UPDLOCK, READPAST)
    WHERE x.ExecutionFinishedOn IS NULL
    AND 
    (
          x.ExecutionStartedOn IS NULL 
       OR x.ExecutionStartedOn < DATEADD(HOUR, -1, GETDATE())
    )
    ORDER BY 
        x.CreatedOn ASC
        /*You may need to also order by Id if CreatedOn isn't unique*/
)
UPDATE 
    q
SET 
    ExecutionStartedOn = GETDATE()
OUTPUT 
    Deleted.Id as Result;

当然，对于大多数队列查询来说，更大的挑战是对其建立索引以使工作易于分发。通常，排除已完成工作 (ExecutionFinishedOn) 的过滤索引和过滤/排序元素上的键（ExecutionStartedOn、CreatedOn）就足够了。

就您而言，您要查找尚未开始的项目以及一个多小时前开始的项目。将它们分成两个独立查找每个配置的“工作人员”可能更有意义，或者如果没有找到尚未开始的行，则添加一些逻辑来查找一个多小时前开始的行。

比较技术

我使用公用表表达式而不是使用子查询进行更新的原因是为了避免查询计划对表进行多次锁定调用。

看一下这个示例，它使用一个名为dbo.WhatsUpLocks的小帮助器视图来汇总会话持有的锁。我还使用扩展事件来观察更新查询运行时在表和相关对象（索引、默认约束等）上获取和释放的锁。

第一种技术

BEGIN TRANSACTION;
    DECLARE
        @id integer, 
        @reputation integer;

    WITH 
        q4 AS
    (
        SELECT TOP (1) 
            fq.*
        FROM dbo.four_queue AS fq WITH(READPAST, ROWLOCK, UPDLOCK)
        WHERE fq.in_process = 0
        ORDER BY 
            fq.id
    )
    UPDATE q4
    SET 
        q4.in_process = 1,
        q4.start_date = SYSDATETIME(),
        @id = q4.id,
        @reputation = q4.reputation
    FROM q4;
    
    SELECT
        wul.*
    FROM dbo.WhatsUpLocks(@@SPID) AS wul;
ROLLBACK;
GO 

这是查询计划，其中包含对该表的单个读取引用：

以下是查询执行期间获取和释放的锁：

以下是事务回滚之前保留的锁：

第二种技术

让我们将其与您最初的尝试进行比较，该尝试应用于我之前链接的帖子中的表设置。

BEGIN TRANSACTION;
    DECLARE
        @id integer, 
        @reputation integer;

    UPDATE 
        q4
    SET
        q4.in_process = 1,
        q4.start_date = SYSDATETIME(),
        @id = q4.id,
        @reputation = q4.reputation
    FROM dbo.four_queue AS q4
    WHERE q4.id = 
    (
        SELECT TOP (1) 
            x.id
        FROM dbo.four_queue AS x WITH (ROWLOCK, UPDLOCK, READPAST)
        WHERE x.in_process = 0
        ORDER BY 
            x.id
    );

    SELECT
        wul.*
    FROM dbo.WhatsUpLocks(@@SPID) AS wul;
ROLLBACK;
GO 

这是查询计划，现在有两个对该表的读取引用：

以下是查询执行期间获取和释放的锁：

以下是事务回滚之前保留的锁：

差异

查询执行期间获取和释放的锁有很大不同。公共表表达式中的数量比使用子查询更新中的少得多，这主要是因为查询计划中只有单个读取和更新引用。

在查询回滚之前，剩余的锁只有细微的差别。我的结果中的底行显示了页面上的 IX 锁，而您的结果显示了页面上的 UIX 锁。

这些差异加起来有多少取决于处理队列时的并发性，但您最好以正确的方式进行处理，这样您就不必担心它稍后会崩溃。

最后一点，我不希望您放弃这样的想法：公用表表达式是有魔力的。他们不是。您可以使用派生表或创建的视图（生成要更新的单个结果）获得相同的结果，而无需使用子查询。在这种情况下，我发现公共表表达式使查询更容易理解。就这些。