Redis事务和锁机制--事务冲突（悲观锁和乐观锁）

乐观锁比较适用于读多写少的情况(多读场景)，悲观锁比较适用于写多读少的情况(多写场景)。

1. 悲观锁

当要对数据库中的某条数据进行修改时，为了防止并发，需要在修改操作执行前对该数据上锁，以防止其他任务修改数据。这种借助数据库锁机制，在修改前先锁定再修改的方式被称为悲观并发控制（悲观锁）

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

之所以叫悲观锁，是它总假设最坏的情况，每次读取数据时都默认其他线程会更改数据，因此需要加锁

悲观锁的分类：

（1）共享锁：又称为读锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。

（2）排他锁：又称为写锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

悲观并发控制实际上是“先取锁再访问”的保守策略，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

2. 乐观锁

乐观锁假设数据一般情况不会造成冲突，每次拿数据的时候，都认为别人不会修改所以不会上锁，但是在更新的时候会判断一下，在此期间是否有别人去更新数据（可使用版本号控制），所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。

乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。乐观锁的实现：

CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。