如何确保Engine与UI节点的RDS数据库更新按生成顺序执行？

我有两个ECS任务（Engine和UI）连接至同一RDS实例，并行更新该数据库。核心异常情况如下：

• UI节点于11:49发起某条记录的更新查询，Engine节点于11:54发起同一条记录的更新查询
• 期望更新按生成顺序执行，但实际UI的更新被Engine的更新抢先执行（哪怕将Engine的查询延迟10秒仍如此）
• 例外场景：若两条查询的时间差超过30秒，更新会按生成顺序正常执行
• 补充架构：第三个ECS节点将Laravel任务分发至SQS队列，由Engine节点消费执行

1. 数据库行级锁+生成时间校验 #

在更新逻辑中加入行级排他锁，同时校验记录的最后更新时间与当前查询的生成时间，确保只有更早生成的请求能执行更新：

// UI/Engine通用更新逻辑
DB::transaction(function () use ($recordId, $newData, $queryGeneratedAt) {
    // 获取行级排他锁，阻止其他事务修改该记录
    $record = DB::table('target_table')
        ->where('id', $recordId)
        ->lockForUpdate()
        ->first();

    // 仅当记录最后更新时间早于当前查询生成时间时，执行更新
    if ($record->updated_at < $queryGeneratedAt) {
        DB::table('target_table')
            ->where('id', $recordId)
            ->update(array_merge($newData, ['updated_at' => now()]));
    }
});

这里的$queryGeneratedAt是查询生成的时间戳（如UI的11:49、Engine的11:54），从根源上保证时序优先级。

2. SQS任务延迟调度优化 #

针对Engine节点从SQS消费的特性，在分发Laravel任务时，根据任务生成时间动态设置延迟：

// 第三个ECS节点的任务分发逻辑
$engineTaskGeneratedAt = Carbon::parse('11:54');
$uiTaskGeneratedAt = Carbon::parse('11:49');
$timeDiff = $engineTaskGeneratedAt->diffInSeconds($uiTaskGeneratedAt);

// 若Engine任务生成时间晚于UI且时间差小于30秒，延迟执行确保UI更新先完成
if ($timeDiff < 30) {
    // 额外添加5秒容错，避免网络波动导致的时序偏差
    dispatch(new EngineUpdateTask($recordId, $newData))->delay($timeDiff + 5);
} else {
    dispatch(new EngineUpdateTask($recordId, $newData));
}

从任务消费层面控制Engine的执行时机，避免它抢在UI更新前触达数据库。

3. 乐观锁版本控制 #

给目标表添加version字段，通过版本号校验避免无序覆盖：

1. 先给表添加字段：

ALTER TABLE target_table ADD COLUMN version INT DEFAULT 1;

2. 更新逻辑示例：

// UI节点更新
$affectedRows = DB::table('target_table')
    ->where('id', $recordId)
    ->where('version', $currentVersion)
    ->update([
        'your_column' => $newValue,
        'version' => DB::raw('version + 1')
    ]);

// 若更新失败（即Engine已抢先更新），可根据业务需求重试或放弃
if ($affectedRows === 0) {
    // 处理更新失败逻辑，比如重试或通知业务端
}

Engine端更新逻辑同理，版本号不匹配时更新会直接失败，保证只有先发起的请求能修改记录。

4. 统一更新入口 #

将所有针对该记录的更新请求统一转发至单个节点（比如UI节点或新增专门的更新服务），由该节点维护一个内存队列，按请求生成时间排序执行，从架构层面消除并行冲突。

短时间差下时序失效，大概率是因为Engine任务从SQS消费时，存在连接建立更快、消费优先级更高的情况，导致它先触达RDS；而30秒以上的时间差会让UI的更新请求自然完成，因此不会出现冲突。

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