深入探讨ThinkPHP数据库悲观锁与乐观锁的实现与应用——从理论到实战的避坑指南
大家好，作为一名常年与ThinkPHP打交道的开发者，我发现在处理高并发下的数据一致性问题时，数据库锁机制是绕不开的话题。很多朋友对“悲观锁”和“乐观锁”这两个概念耳熟能详，但在ThinkPHP项目中具体如何选择、如何实现，却常常踩坑。今天，我就结合自己的实战经验，带大家深入探讨一下ThinkPHP中这两种锁的实现方式、应用场景以及那些我亲自踩过的“坑”。
一、核心概念：悲观锁与乐观锁的本质区别
在开始写代码之前，我们必须先理清思路。这就像上战场前得先认识自己的武器。
悲观锁（Pessimistic Lock）：顾名思义，持一种“悲观”态度。它总是假设最坏的情况，认为每次去操作数据时，别人都会修改。因此，在操作开始前就直接上锁，操作完成后才释放。在数据库中，通常通过 `SELECT ... FOR UPDATE` 语句实现。它的特点是“先取锁，再访问”，能强有力地保证数据一致性，但会带来较多的性能开销和死锁风险。
乐观锁（Optimistic Lock）：持一种“乐观”态度。它假设多用户并发操作时，冲突的概率很低。因此，它不会在读取数据时加锁，而是在更新数据时，通过一个版本号（version）或时间戳字段，来判断数据在此期间是否被其他事务修改过。如果被修改过，则更新失败，需要重试。它的特点是“先访问，更新时再检查”，性能较好，但在冲突频繁的场景下，重试成本会很高。
简单总结：悲观锁是“为数据上保险”，乐观锁是“给数据贴标签”。选择哪种，完全取决于你的业务并发冲突概率。
二、ThinkPHP中的悲观锁实战与踩坑
ThinkPHP的数据库查询构造器完美支持悲观锁，主要通过 `lock(true)` 方法来实现，底层会生成 `FOR UPDATE` 子句。让我们来看一个经典的“商品库存扣减”场景，这是悲观锁最典型的用武之地。
1. 基础实现：
// 我们假设在商品秒杀的逻辑中
Db::startTrans(); // 开启事务
try {
// 关键步骤：使用 lock(true) 锁定要操作的商品行
$goods = Db::table('goods')
->where('id', 1001)
->lock(true)
->find();
if ($goods && $goods['stock'] > 0) {
// 扣减库存
$updateResult = Db::table('goods')
->where('id', 1001)
->where('stock', $goods['stock']) // 此处的where条件与查询时一致，是良好实践
->update([
'stock' => Db::raw('stock-1'),
'update_time' => time()
]);
if ($updateResult) {
// 生成订单等后续操作...
Db::commit(); // 提交事务，释放锁
return '抢购成功！';
}
}
Db::rollback(); // 回滚事务，释放锁
return '库存不足或操作失败';
} catch (Exception $e) {
Db::rollback();
// 记录日志
return '系统异常';
}2. 我踩过的坑（重要！）：
- 事务与锁必须共存： `FOR UPDATE` 锁只在事务中生效。如果你忘了开事务（`Db::startTrans()`），`lock(true)` 将不会生效，锁也就形同虚设。这是我早期犯过的低级错误。
- 死锁风险： 如果多个事务以不同的顺序锁定多行记录，极易引发死锁。例如，事务A先锁id=1，再锁id=2；事务B先锁id=2，再锁id=1。解决方案是始终以固定的全局顺序访问资源（比如按id升序）。
- 锁粒度要精细： 务必通过精确的 `where` 条件锁定必要的行，避免锁住整张表。`->where('id', 1001)->lock(true)` 是行锁，而 `->lock(true)` 后跟全表更新可能会导致表锁，性能灾难！
三、ThinkPHP中的乐观锁优雅实现
ThinkPHP模型层为乐观锁提供了开箱即用的支持，非常优雅。它默认需要一个 `version` 字段（可在模型内配置为其他字段）。
1. 数据表准备：
首先，你的数据表需要一个版本号字段，通常是无符号整型。
ALTER TABLE `goods` ADD COLUMN `version` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '乐观锁版本号';2. 模型配置与使用：
// Goods 模型
namespace appmodel;
use thinkModel;
class Goods extends Model
{
// 开启乐观锁，并指定版本号字段名（默认为‘version’）
protected $optimisticLock = 'version';
// 或者，你也可以在初始化方法中动态设置
/* protected static function init()
{
self::event('before_update', function ($goods) {
$goods->where('version', $goods->version);
});
} */
}
// 在业务逻辑中使用（同样是库存扣减）
$goods = Goods::find(1001);
if ($goods && $goods->stock > 0) {
$goods->stock = $goods->stock - 1;
// 关键点：save方法内部会自动检测version字段
// 它会在更新时带上 WHERE id=1001 AND version={查询时的version}
// 如果受影响行数为0，表示数据已被他人修改，保存失败。
$result = $goods->save();
if ($result) {
return '更新成功！';
} else {
// 这里就是乐观锁冲突了！
return '数据已被修改，请重试';
}
}3. 手动实现与重试机制：
有时候我们不想用 `version` 字段，或者想用时间戳，或者需要更复杂的冲突判断。这时可以手动实现：
$maxRetries = 3; // 最大重试次数
for ($i = 0; $i where('id', 1001)->find();
if ($goods['stock'] where('id', 1001)
->where('stock', $goods['stock']) // 核心：用旧库存值作为“版本标识”
->update([
'stock' => Db::raw('stock-1'),
'update_time' => time()
]);
if ($updateResult) {
// 更新成功，跳出循环
break;
}
// 更新失败（受影响行数为0），说明stock已被其他进程修改，循环重试
usleep(100000); // 等待100毫秒后重试，避免密集循环
}
if ($i == $maxRetries) {
return '操作过于频繁，请稍后再试';
}4. 乐观锁的坑：
- ABA问题： 版本号从1变成2又变回1，仅用数值版本号无法察觉。对于极端敏感的业务，可以使用更复杂的标识（如时间戳+随机数），或配合其他逻辑。但在大部分电商场景中，数值版本号已足够。
- 重试风暴： 在高冲突下，大量请求重试会增加系统负担。一定要设置最大重试次数，并考虑结合队列进行异步处理或流量削峰。
四、如何选择：一张图与一个原则
选择原则： 冲突频率 × 重试成本 与 加锁开销 的权衡。
- 选悲观锁： 数据冲突概率非常高（如金融账户余额扣减、稀缺商品秒杀），且你无法承受乐观锁频繁失败重试带来的复杂逻辑和延迟。愿意为强一致性牺牲部分性能。
- 选乐观锁： 数据冲突概率较低（如文章点赞数更新、个人资料修改），读远多于写，追求系统高吞吐量。你的业务能接受“更新失败请重试”这样的交互。
最后的心得： 在现代Web开发中，尤其是互联网应用，我更倾向于优先考虑乐观锁。因为它无锁的设计更契合高并发的需求，配合重试机制和良好的用户体验提示（如“内容已更新，请刷新”），往往能取得更好的综合效果。而悲观锁，我通常把它留给那些“不容有失”的核心财务或状态流转业务。
希望这篇结合了实战与踩坑经验的总结，能帮助你在下一个ThinkPHP项目中，更加游刃有余地处理并发数据问题。记住，没有最好的锁，只有最适合你业务场景的锁。
评论(0)