加锁之前的三秒钟
前十五篇教你把锁用好，这一篇先劝你慢点用。凡是「我要抢锁」的念头冒出来，先回答一个问题：互斥的对象到底是「一行数据」还是「一段逻辑」？如果答案是前者——你保护的是某个账户余额、某条任务记录、某个订单状态——那大概率不需要分布式锁：数据库自带的并发控制（乐观锁、唯一索引、行锁）就是为这事生的，它们运行在数据的属地，没有锁服务、没有 TTL、没有看门狗，比任何分布式锁都便宜且可靠。分布式锁真正的领地是后者：保护一段横跨多个资源、多台机器的执行逻辑。本篇把四个替代方案排成纵队，逐个看适用与代价。
方案一：乐观锁版本号
第 1 篇的扣款竞态，最便宜的解法是给账户表加 version 字段：
-- 读余额与版本
SELECT balance, version FROM account WHERE card_no = '8801';
-- 应用层判断余额充足后，带版本号更新
UPDATE account SET balance = balance - 80, version = version + 1
WHERE card_no = '8801' AND version = 17;
-- 影响行数 = 0：版本已被别人推进，余额判断作废，读新值重试并发冲突时「后到者作废重试」，没有锁服务、没有超时问题、天然防死锁（失败即返回，不等待）。代价是高冲突下的重试风暴——一百个请求更新同一行，九十九个要重试，读放大明显。适合冲突率低的行级更新；冲突率高的（热点账户），见 MySQL 系列第 17 篇的缓冲记账，或直接上队列。
方案二：唯一索引
「防止重复做某件事」类需求（重复发券、重复建单、重复执行任务），唯一索引是终极答案：用业务键做唯一约束，重复操作在数据库层直接被拒，原子性由存储引擎背书，竞态窗口为零——分布式事务系列第 10 篇把它称为「最后的墙」。定时任务防重跑的变体是「抢占更新」：
UPDATE task SET status = 'RUNNING', owner = 'node-2'
WHERE id = 42 AND status = 'PENDING';
-- 影响行数 = 1：我抢到了；= 0：别人在跑或跑过了三台实例同一秒执行同一条 UPDATE，数据库行锁保证串行，只有一个人的影响行数是 1——不用抢任何锁，任务执行权就分配好了。老王三家门店的当班调度，用的就是这招。
方案三：行锁 select for update
读和写必须一起串行的场景（读余额、判断、扣款三步原子化），悲观行锁一步到位：事务里 select ... for update 锁住该行，判断与更新在同一事务内完成，其他事务阻塞等待。它把第 1 篇的竞态窗口焊死了，代价也明码标价：持锁期间数据库连接被占用，长事务拖垮连接池；锁粒度大时死锁风险上升。适合「事务短、冲突集中在确定行」的场景；跨库跨服务的逻辑，行锁鞭长莫及，那才是分布式锁的活。
方案四：队列串行化
高频写同一资源的终极方案是干脆取消并发：所有变更请求进消息队列，同一分区/队列的消息串行消费——并发问题变成了排队问题，锁彻底消失。消息队列系列第 6 篇的顺序消息在此派上用场：按账户 ID 分区，同一账户的消息落同一分区，消费端单线程处理，余额更新天然有序。代价是响应延迟（异步化，用户等不到同步结果）与吞吐规划（分区数、消费者数）；秒杀扣库存、账务流水这类「结果可以异步、正确性必须满分」的场景是它的主场。
| 方案 | 适用 | 代价 |
|---|---|---|
| 乐观锁版本号 | 低冲突的行级更新 | 高冲突下重试风暴 |
| 唯一索引 / 抢占更新 | 防重复、任务认领 | 只覆盖「一次事」，不保护逻辑段 |
| 行锁 for update | 短事务的读改写原子化 | 占连接、死锁风险 |
| 队列串行化 | 高频写的异步化收敛 | 响应延迟、架构改造 |
决策口诀收拢：防重复用唯一索引，改数据用乐观锁，短事务用行锁，高并发用队列；跨资源跨服务的逻辑段，才轮到分布式锁。下一篇讲锁正确性的最后一块拼图——fencing token：当锁的持有者是个幽灵，下游凭什么拒绝它。
评论 (0)