乐观锁和悲观锁

目录

• 乐观锁和悲观锁是什么/可以被用在什么样的场景下？
• 乐观锁和悲观锁的区别？

---

引用一段比较经典的描述 “数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。”

1. 乐观锁的原理：
   乐观锁的实现引入的版本号的机制，版本号version id 记录的是当前数据被修改的次数。

加入当前的money = 100，version = 1，一个事务试图给money字段扣款30元。需要三步：

1. 查询出money = 100， version = 1
2. left = money - 30 = 70，cur-version = version + 1 = 2
3. 写入 money = left ，verson = cur-version

写入的时候，需要确保cur-version一定大于version。这样会保证在这段时间没有其他事务对这个字段进行修改。

举个例子，事务1是消费30元的亲求，事务2是添加50元的请求，如果同时操作的话，乐观锁的机制是如果避免数据的一致性被破坏的。

事务1	事务2
查询出money = 100， version = 1
left = money - 30 = 70，cur-version = version + 1 = 2
	查询menoy = 100，version=1
	left = money + 50 = 150，cur-version = version + 1 = 2
	写入 menoy = 150， version = 2
写入 （这个时候db中的version已经是2了。所以，不允许事务1再次写入了）

当事务1在写入的时候，事务2已经对数据进行了修改，这个时候version号变大，事务1再写入的时候，发现version号已经等于自己的版本号了，说明有其他的事务已经修改过了，那么事务1的操作需要retry。

• 为什么起名叫乐观锁？
  比起悲观锁事务修改之间先加锁，然后在修改，然后再释放锁。乐观锁假设事务不会同时修改（抱着一个乐观的预期）如果同时修改了，通过版本号的机制保证事务的一致性。

• 什么场景可以使用乐观锁？
  一个多读少写的环境适合用乐观锁，因为这样的发生版本号冲突的概率会很低。

---

前几天看来redis，redis和关系型数据库在控制并发事务的一致性的时候，关系型数据库会对被访问的数据进行加锁，知道事务被commit。如果有其他的事务试图对被加锁的数据进行加入，那这个客户端会被阻塞。但是，缺点在于持有锁的客户端会使数据库的性能下降。

redis使用的watch命令，来保证自己从mult 到exec之间的过程中，数据没有被修改。当其他的客户端修改了数据，使用了watch的命令会收到通知。这两种的数据库，保证数据的一致性的方法，分别的原理就是乐观锁和悲观锁。

---

• 参考：

1. http://www.hollischuang.com/archives/909

2. https://zhuanlan.zhihu.com/p/40211594