分布式场景下数据库竞态问题：如何实现非全表锁同步？

核心方案：数据库行级锁+原子操作 #

跨进程/服务实例的竞态无法靠JVM内部的synchronized解决，数据库层面的行级锁是可行方案，且能避免锁定整张表，核心思路是把「选择可用Client」和「标记占用」变成原子操作，消除中间的竞争窗口。

1. SELECT ... FOR UPDATE 行级排他锁 #

将查询和锁定合并为一步，确保只有当前线程能拿到目标Client的修改权限：

• 直接查询未被占用且符合过滤条件的Client，同时给该行加排他锁
• 在同一个事务内完成锁行、更新userId、提交释放锁的操作

示例SQL（假设clients表主键为id，user_id为空表示未被占用）：

SELECT id, user_id FROM clients 
WHERE [你的过滤条件] AND user_id IS NULL 
LIMIT 1 FOR UPDATE;

对应Java代码逻辑：

// 原子查询并锁定可用Client（需在事务内执行）
Client client = clientRepository.findAndLockAvailableClient(...);
if (client != null) {
    // 此时只有当前线程能修改该Client
    client.setUser(userId);
    clientRepository.save(client);
}

注意事项：

• 必须使用支持行级锁的数据库引擎（如MySQL InnoDB），MyISAM不支持行级锁会锁整张表
• 锁的持有时间要尽可能短，避免影响其他线程的操作

2. UPDATE ... WHERE 原子更新 #

利用数据库UPDATE语句的原子性直接抢占Client，无需显式加锁：

• 尝试将一个未被占用的Client的user_id更新为当前userId，通过返回的更新行数判断是否抢占成功
• 若更新行数>0，说明抢占成功；若为0，说明无可用Client，可重试或返回失败

示例SQL：

UPDATE clients 
SET user_id = ? 
WHERE [你的过滤条件] AND user_id IS NULL 
LIMIT 1;

对应Java代码逻辑：

int updatedRows = clientRepository.claimClient(userId, ...);
if (updatedRows > 0) {
    // 抢占成功，查询该Client详情
    Client client = clientRepository.findClaimedClient(userId, ...);
} else {
    // 无可用Client，处理重试或提示逻辑
}

优势：

• 无需长事务，性能更高
• 完全依赖数据库原子操作，避免锁持有过长带来的性能问题

3. 原逻辑的问题根源 #

原代码将「查询候选Client」和「标记占用」拆分为两步，中间存在时间窗口，导致多个线程可能拿到同一个Client。必须将这两步合并为原子操作，才能从根源解决竞态问题。

额外优化建议 #

• 给clients表的user_id和过滤条件字段建立联合索引，加快查询/更新速度，缩短锁的持有时间
• 若业务允许，可在抢占失败时增加有限次数的重试逻辑，提升Client分配成功率

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