悲观锁、乐观锁的区别及使用场景

悲观锁、乐观锁的区别及使用场景

悲观锁（Pessimistic Lock）：
每次获取数据的时候，都会担心数据被修改，所以每次获取数据的时候都会进行加锁，确保在自己使用的过程中数据不会被别人修改，使用完成后进行数据解锁。由于数据进行加锁，期间对该数据进行读写的其他线程都会进行等待。

乐观锁（Optimistic Lock）：
每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁，但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新，如果数据没有被其他线程修改，则进行数据更新。由于数据没有进行加锁，期间该数据可以被其他线程进行读写操作。
操作方式：
版本号控制

   start transaction
   first_version = get_cur_version() // 获取当前数据版本
   update_data(version+=1)           // 更新操作版本号+1
   cur_version = get_cur_version()   // 提交更新时，获取版本号
   if first_version == cur_version   // 比较提交时的版本号与第一次获取的版本号，如果一致，那么认为                                    //资源是最新的，可以更新
   then commit  else rollback or raise exception  // 否则回滚或者抛出异常

时间戳控制

 start transaction
 first_timestamp = get_cur_timestamp()
 update_data(timestamp=get_sys_cur_timestamp)
 if first_timestamp = get_cur_timestamp()
 then commit 
 else rollback or raise Exception

适用场景：

悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。

总结：两种所各有优缺点，读取频繁使用乐观锁，写入频繁使用悲观锁。

像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适,之所以用悲观锁就是因为两个用户更新同一条数据的概率高，也就是冲突比较严重的情况下，所以才用悲观锁.

悲观锁比较适合强一致性的场景，但效率比较低，特别是读的并发低。乐观锁则适用于读多写少，并发冲突少的场景。