数据库事务隔离：乐观锁与悲观锁在PHP中的实现
在Web应用开发中，你有没有遇到过这样的场景：多个用户几乎同时对同一账户进行扣款或修改，结果数据出现了错乱？这背后，其实就是并发控制的问题。要解决它，绕不开两个核心概念：乐观锁和悲观锁。今天，我们就来聊聊它们在PHP中的具体实现方式，看看如何用代码来守护数据的一致性。
一、悲观锁的PHP实现
悲观锁的思路很直接：它默认冲突是常态，所以在动手操作数据之前，就先“占住”它，不让别人碰。这就像去图书馆借一本热门书，管理员会先把它锁在柜子里，等你办完手续再放回去。在MySQL里，我们通常借助SELECT ... FOR UPDATE语句，再配合事务来完成。
首先，需要开启一个数据库事务。使用PDO的话，就是调用beginTransaction()方法。
接着，执行带锁的查询。比如SELECT * FROM users WHERE id = 1 FOR UPDATE。这条语句一执行，id为1的那条记录就被锁定了，直到你的事务提交或回滚，其他想修改它的事务都得等着。
立即学习“PHP免费学习笔记（深入）”；
然后，在锁的保护下，安心执行业务逻辑。例如，计算并更新用户余额：UPDATE users SET balance = balance - 100 WHERE id = 1。
最后，根据业务结果，选择提交事务（commit()）来确认更改并释放锁，或者回滚事务（rollback()）来撤销所有操作并解锁。
二、基于版本号的乐观锁实现
与悲观锁相反，乐观锁认为冲突不常发生。它不会一开始就加锁，而是在最后提交更新时，检查一下数据在此期间有没有被别人动过。怎么检查呢？一个经典的做法是给数据表加一个version字段。
第一步，读取数据时，把当前的版本号也一并查出来：SELECT id, name, balance, version FROM users WHERE id = 1。
第二步，在内存里完成业务计算，比如判断余额是否足够，并算出新的余额。
第三步，也是最关键的一步，执行条件更新：UPDATE users SET balance = ?, version = version + 1 WHERE id = ? AND version = ?。这里把之前读到的版本号作为条件，只有版本号没变，更新才会成功。
第四步，检查影响行数。如果rowCount()返回1，恭喜，更新成功。如果返回0，那就意味着在你读取之后、更新之前，数据已经被其他请求修改了，本次更新失败，通常需要重试或向用户抛出异常。
三、基于时间戳的乐观锁实现
原理和版本号机制一模一样，只是校验的“信物”换成了数据行最后更新的时间戳（比如updated_at字段）。这对于那些已经存在时间戳字段、不方便再加version字段的表来说，是个很实用的选择。
首先，读取数据和当前的时间戳：SELECT id, name, balance, updated_at FROM users WHERE id = 1。
接着，处理业务逻辑。
然后，执行带时间戳校验的更新：UPDATE users SET balance = ?, updated_at = NOW() WHERE id = ? AND updated_at = ?。
最后，验证结果。同样，如果影响行数为0，就表明数据已被他人抢先更新，当前操作应当被拒绝。
四、使用Redis实现分布式悲观锁
当你的PHP应用部署在多台服务器上时，数据库的行锁就管不住跨进程的并发了。这时候，需要一个全局都能看见的“信号灯”，Redis分布式锁就派上了用场。它的核心是利用Redis的SETNX（或带参数的SET）命令的原子性。
第一步，生成一个唯一的锁标识键，例如“lock:user:1”，其中的1可以是对应的用户ID。
第二步，尝试获取锁。执行Redis::set($key, $unique_value, ['nx', 'ex' => 10])。这条命令的意思是，只有当键不存在（nx）时才设置它，并给它一个10秒的过期时间（ex），这是为了防止客户端崩溃导致锁永远无法释放。
第三步，判断返回值。如果返回TRUE，说明成功拿到了锁，可以放心地去操作数据库了。如果返回FALSE，说明锁已被他人持有，请求需要等待或直接返回“操作冲突”的提示。
第四步，操作完成后，务必释放锁。注意，最好使用Lua脚本，通过比对锁值来原子性地删除键，避免误删了其他请求后来设置的锁。
五、CAS风格的乐观锁封装类
在业务代码里到处写版本号校验和重试逻辑，显然不够优雅。更好的做法是，把这些通用逻辑封装成一个工具类，这就是CAS（Compare-And-Swap）风格的工具类。它把“读取-计算-更新”这个循环流程包装起来，自动处理失败重试。
首先，定义重试次数的上限，比如默认3次，防止在极端高并发下陷入无限循环。
然后，在一个循环内，执行标准的“读取数据 -> 业务计算 -> 尝试更新”流程。每次更新失败，都重新读取最新的数据和版本号。
在每次更新前，工具类会自动校验当前内存中的版本号是否与数据库中的一致。
如果循环达到最大重试次数后更新仍未成功，工具类便会终止操作，抛出一个清晰的OptimisticLockException异常，让上层业务逻辑能妥善处理。
说到底，选择乐观锁还是悲观锁，没有绝对的优劣，关键看你的业务场景。冲突频繁、临界区操作耗时长的，悲观锁更省心；冲突概率低、追求更高吞吐量的，乐观锁往往表现更佳。理解它们的原理，并在PHP中熟练运用，是构建稳健并发系统的基本功。
