并发处理存储过程优化：实现同一时间仅首个请求执行

你的当前方案是基于乐观并发控制（通过RowVersion检查），但这种模式的问题是：只有当并发请求完成计算后才会发现冲突并回滚，没法提前阻止其他请求进入执行流程。要实现“仅第一个请求执行，其余直接拒绝”的需求，我们需要切换到悲观锁或者引入排他性的执行标记，确保同一时间只有一个请求能进入存储过程的核心逻辑。

下面是几种可行的实现方案，以SQL Server为例（不同数据库语法略有差异，但思路通用）：

方案1：使用数据库排他锁直接锁定核心表 #

在事务起始阶段就对Table A施加排他锁，这样后续的并发请求会被直接阻塞或者无法获取锁，我们可以通过锁超时设置让后续请求直接返回失败，而不是等待。

示例存储过程代码： #

CREATE PROCEDURE YourProcedureName
AS
BEGIN
    SET NOCOUNT ON;
    SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

    DECLARE @IsLockAcquired BIT = 0;
    BEGIN TRY
        -- 设置锁超时时间（1秒，超时则放弃）
        SET LOCK_TIMEOUT 1000;

        BEGIN TRANSACTION;

        -- 获取Table A的表级排他锁，若只需锁定特定行可修改WHERE条件
        SELECT @IsLockAcquired = 1
        FROM TableA WITH (TABLOCKX)
        WHERE 1=1;

        -- 检查是否成功获取锁
        IF @IsLockAcquired = 0
        BEGIN
            ROLLBACK TRANSACTION;
            RAISERROR('已有其他请求正在执行该操作，请稍后重试', 16, 1);
            RETURN;
        END

        -- ********** 执行你的计算操作 **********
        -- ... 你的计算逻辑 ...

        -- 执行更新操作（包括Table A）
        UPDATE TableA SET ... WHERE ...;
        UPDATE OtherTable SET ... WHERE ...;

        COMMIT TRANSACTION;
        PRINT '操作执行成功';
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        THROW; -- 抛出异常给调用方
    END CATCH
END

注意点： #

• TABLOCKX是表级排他锁，会阻止任何其他会话对Table A进行读写操作，如果Table A有其他业务操作，建议改用行级排他锁（比如UPDLOCK, HOLDLOCK锁定特定行），减少锁粒度。
• LOCK_TIMEOUT设置为1000毫秒，确保后续请求不会长时间等待，直接返回失败。

方案2：引入“执行状态”标记表 #

如果不想直接锁定业务表，可以创建一个专门的状态表，用来标记该存储过程是否正在执行，结合UPDLOCK和ROWLOCK实现原子性的状态检查与更新。

步骤1：创建状态表 #

CREATE TABLE ProcedureExecutionStatus (
    ProcedureName VARCHAR(100) PRIMARY KEY,
    IsExecuting BIT NOT NULL DEFAULT 0,
    LastExecutionTime DATETIME NOT NULL DEFAULT GETDATE()
);

-- 初始化目标存储过程的状态
INSERT INTO ProcedureExecutionStatus (ProcedureName, IsExecuting)
VALUES ('YourProcedureName', 0);

步骤2：修改存储过程 #

CREATE PROCEDURE YourProcedureName
AS
BEGIN
    SET NOCOUNT ON;
    SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

    DECLARE @CanExecute BIT = 0;
    BEGIN TRY
        BEGIN TRANSACTION;

        -- 原子性检查并更新执行状态：仅当IsExecuting=0时，将其设为1
        UPDATE ProcedureExecutionStatus WITH (UPDLOCK, ROWLOCK)
        SET IsExecuting = 1, LastExecutionTime = GETDATE()
        WHERE ProcedureName = 'YourProcedureName' AND IsExecuting = 0;

        -- 检查是否成功抢占执行权限
        SET @CanExecute = @@ROWCOUNT;

        IF @CanExecute = 0
        BEGIN
            ROLLBACK TRANSACTION;
            RAISERROR('已有其他请求正在执行该操作，请稍后重试', 16, 1);
            RETURN;
        END

        -- ********** 执行计算操作 **********
        -- ... 你的计算逻辑 ...

        -- 执行更新操作（包括Table A）
        UPDATE TableA SET ... WHERE ...;
        UPDATE OtherTable SET ... WHERE ...;

        -- 重置执行状态
        UPDATE ProcedureExecutionStatus
        SET IsExecuting = 0
        WHERE ProcedureName = 'YourProcedureName';

        COMMIT TRANSACTION;
        PRINT '操作执行成功';
    END TRY
    BEGIN CATCH
        -- 异常时必须重置执行状态，避免后续请求被永久阻塞
        IF @@TRANCOUNT > 0
        BEGIN
            UPDATE ProcedureExecutionStatus
            SET IsExecuting = 0
            WHERE ProcedureName = 'YourProcedureName';
            ROLLBACK TRANSACTION;
        END
        THROW;
    END CATCH
END

注意点： #

• 这种方式不会影响业务表的正常操作，锁粒度更小，适合Table A有其他并发业务的场景。
• 异常处理中一定要重置IsExecuting状态，防止存储过程执行崩溃后导致所有后续请求无法执行。

为什么原来的RowVersion方案不适用？ #

原来的方案是乐观并发：允许所有请求进入计算阶段，只有在最后更新时才检查RowVersion是否变化，冲突后回滚。但这会导致多个请求都执行了计算操作，最后只有一个成功，既浪费资源，也不符合你“其余请求不允许执行”的需求。我们需要的是悲观并发：在请求进入核心逻辑前就阻止并发，确保只有第一个请求能执行。

内容的提问来源于stack exchange，提问作者Station E1