深入理解Yii2.0乐观锁与悲观锁的原理与使用

从上面的代码中，我们不难得出：

1. 当 optimisticLock() 返回 null 时，乐观锁不会被启用。
2. 版本号只增不减。
3. 通过乐观锁的条件有2个，一是主键要存在，二是要能够完成更新。
4. 当启用乐观锁后，只有下列两种情况会抛出 StaleObjectException 异常：
   1. 当记录在被别人删除后，由于主键已经不存在，更新失败。
   2. 版本号已经变更，不满足更新的第二个条件。

删除过程

与更新过程相比，删除过程的乐观锁，更简单，更好理解。代码仍在 yii\db\BaseActiveRecord 中:

public function delete()
{
  $result = false;
  if ($this->beforeDelete()) {
    // 删除的SQL语句中，WHERE部分是主键
    $condition = $this->getOldPrimaryKey(true);
    // 获取版本号字段的字段名，比如 ver
    $lock = $this->optimisticLock();
    // 如果启用乐观锁，那么WHERE部分再加一个条件，版本号
    if ($lock !== null) {
      $condition[$lock] = $this->$lock;
    }
    $result = $this->deleteAll($condition);
    if ($lock !== null && !$result) {
      throw new StaleObjectException('The object being deleted is outdated.');
    }
    $this->_oldAttributes = null;
    $this->afterDelete();
  }
  return $result;
}

比起更新过程，删除过程确实要简单得多。唯一的区别就是省去了版本号＋1的步骤。 都要删除了，版本号＋1有什么意义？

乐观锁失效

乐观锁存在失效的情况，属小概率事件，需要多个条件共同配合才会出现。如：

1. 应用采用自己的策略管理主键ID。如，常见的取当前ID字段的最大值＋1作为新ID。
2. 版本号字段 ver 默认值为 0 。
3. 用户A读取了某个记录准备修改它。该记录正好是ID最大的记录，且之前没被修改过， ver 为默认值 0。
4. 在用户A读取完成后，用户B恰好删除了该记录。之后，用户C又插入了一个新记录。
5. 此时，阴差阳错的，新插入的记录的ID与用户A读取的记录的ID是一致的， 而版本号两者又都是默认值 0。
6. 用户A在用户C操作完成后，修改完成记录并保存。由于ID、ver均可以匹配上， 因此用户A成功保存。但是，却把用户C插入的记录覆盖掉了。

乐观锁此时的失效，根本原因在于应用所使用的主键ID管理策略， 正好与乐观锁存在极小程度上的不兼容。

两者分开来看，都是没问题的。组合到一起之后，大致看去好像也没问题。 但是bug之所以成为bug，坑之所以能够坑死人，正是由于其隐蔽性。

对此，也有一些意见提出来，使用时间戳作为版本号字段，就可以避免这个问题。 但是，时间戳的话，如果精度不够，如毫秒级别，那么在高并发，或者非常凑巧情况下， 仍有失效的可能。而如果使用高精度时间戳的话，成本又太高。

使用时间戳，可靠性并不比使用整型好。问题还是要回到使用严谨的主键成生策略上来。

悲观锁

正如其名字，悲观锁（pessimistic locking）体现了一种谨慎的处事态度。其流程如下：

1. 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
2. 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
3. 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
4. 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

悲观锁确实很严谨，有效保证了数据的一致性，在C/S应用上有诸多成熟方案。 但是他的缺点与优点一样的明显：

1. 悲观锁适用于可靠的持续性连接，诸如C/S应用。 对于Web应用的HTTP连接，先天不适用。
2. 锁的使用意味着性能的损耗，在高并发、锁定持续时间长的情况下，尤其严重。 Web应用的性能瓶颈多在数据库处，使用悲观锁，进一步收紧了瓶颈。
3. 非正常中止情况下的解锁机制，设计和实现起来很麻烦，成本还很高。
4. 不够严谨的设计下，可能产生莫名其妙的，不易被发现的， 让人头疼到想把键盘一巴掌碎的死锁问题。

总体来看，悲观锁不大适应于Web应用，Yii团队也认为悲观锁的实现过于麻烦， 因此，ActiveRecord也没有提供悲观锁。

作为Yii的构成基因之一的Ruby on rails，他的ActiveReocrd模型，倒是提供了悲观锁， 但是使用起来也很麻烦。

悲观锁的实现