1.乐观锁介绍
- 乐观锁（Optimistic Locking） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
1.1 乐观锁的实现方式
- 使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。
何谓数据版本？ 即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
图例说明
如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。
示例代码:
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
- 乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）[时间戳类型: 行数据更新时, 时间会自动更新], 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。
- 乐观锁的实现
1.CAS(Compare And Swap)
2.MVCC(Multi-Version Concurrency Control)- 乐观锁特点
1. 并发度高
2. 程序实现，不会存在死锁
2. 悲观锁介绍
- 悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠
数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
- 以MySQL 的InnoDB 为例，预设的Tansaction isolation level 为REPEATABLE READ.[要使用悲观锁，我们必须关闭mysql数据库的自动提交属性, set autocommit=0]
- SELECT 的读取锁的两种方式:
1. SELECT ... LOCK IN SHARE MODE
2. SELECT ... FOR UPDATE
两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。而主要的不同在于LOCK IN SHARE MODE 在有一方事务要Update 同一个表单时很容易造成死锁 。
简单的说，如果SELECT 后面若要UPDATE 同一个表单，最好使用SELECT ... UPDATE。
- MySQL SELECT ... FOR UPDATE 的Row Lock(行锁)与Table Lock(表锁).
由于InnoDB 预设是Row-Level Lock，所以只有「明确」的指定主键，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住).
1.明确指定主键，并且有此数据，row lock
2.明确指定主键，若查无此数据，无lock
3.无主键 /主键不明确，table lock- 除了主键外，使用索引也会影响数据库的锁定级别
1.明确指定索引，并且有此数据，row lock
2.明确指定索引，若查无此数据，无lock
- 悲观锁特点
1.并发度小
2.依靠数据实现
- Mysql 书籍推荐
- 《MySQL技术内幕 InnoDB 存储引擎》
- 《高性能MySQL（第3版）》
参考博客:
