MySQL中的乐观锁,悲观锁和MVCC全面解析

前言

在数据库的实际使用过程中，我们常常会遇到不希望数据被同时写或者读的情景，例如秒杀场景下，两个请求同时读到系统还有库存1个，然后又先后把库存更新为0，这时候就会出现超卖的情况，这时候货物的实际库存和我们的记录就会对应不上了。

为了解决这种资源竞争导致的数据不一致等问题，我们需要有一种机制来进行保证数据的正确访问和修改，而在数据库中，这种机制就是数据库的并发控制。其中乐观并发控制，悲观并发控制和多版本并发控制是数据库并发控制主要采用的技术手段。

悲观并发控制

本质

维基百科：在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作读某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。

事实上我们常说的悲观锁并不是一种实际的锁，而是一种并发控制的思想，悲观并发控制对于数据被修改持悲观的态度，认为数据被外界访问时，必然会产生冲突，所以在数据处理的过程中都采用加锁的方式来保证对资源的独占。

数据库的锁机制其实都是基于悲观并发控制的观点进行实现的，而且按照实际使用情况，数据库的锁又可以分为许多种类，具体可以见我后面的文章。

实现方式

数据库悲观锁的加锁流程大致如下：

开始事务后，按照操作类型给需要加锁的数据申请加某一类锁：例如共享行锁等
加锁成功则继续后面的操作，如果数据已经被加了其他的锁，而且和现在要加的锁冲突，则会加锁失败（例如已经加了排他锁），此时需等待其他的锁释放（可能出现死锁）
完成事务后释放所加的锁

优缺点

优点：

悲观并发控制采取的是保守策略：“先取锁，成功了才访问数据”，这保证了数据获取和修改都是有序进行的，因此适合在写多读少的环境中使用。当然使用悲观锁无法维持非常高的性能，但是在乐观锁也无法提供更好的性能前提下，悲观锁却可以做到保证数据的安全性。

缺点：
由于需要加锁，而且可能面临锁冲突甚至死锁的问题，悲观并发控制增加了系统的额外开销，降低了系统的效率，同时也会降低了系统的并行性。

乐观并发控制

本质

维基百科：在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。
乐观并发控制对数据修改持乐观态度，认为即使在并发环境中，外界对数据的操作一般是不会造成冲突，所以并不会去加锁，而是在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，则让返回冲突信息，让用户决定如何去做下一步，比如说重试或者回滚。

可以看出，乐观锁其实也不是实际的锁，甚至没有用到锁来实现并发控制，而是采取其他方式来判断能否修改数据。乐观锁一般是用户自己实现的一种锁机制，虽然没有用到实际的锁，但是能产生加锁的效果。

实现方式

CAS（比较与交换，Compare and swap） 是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。实现非阻塞同步的方案称为“无锁编程算法”（ Non-blocking algorithm）。

乐观锁基本都是基于 CAS（Compare and swap）算法来实现的。我们先来看下CAS过程，一个CAS操作的过程可以用以下c代码表示:

int cas(long *addr, long old, long new)
{
 /* Executes atomically. */
 if(*addr != old)
  return 0;
 *addr = new;
 return 1;
}