Redis分布式锁

乐观锁与悲观锁

悲观锁（Pessimistic Lock）：

每次拿数据时，总会以为数据会被修改。所以每次在拿数据的时候都会上锁，这样别人就无法操作数据，直到自己操作完才会释放锁

乐观锁（Optimistic Lock）：

每次拿数据时，总会以为数据不会被修改。所以就不上锁了，但是如果要更新数据，就会在更新前检查数据是否被修改。如果被修改，则重新读取再更新，一直循环直到更新成功为止。

乐观锁VS悲观锁

1.悲观锁阻塞事务，乐观锁回滚重试。
2.乐观锁适用于写比较少的情况下，即冲突很少发生时，可以省去锁的开销，加大了系统吞吐量
3.悲观锁适用于写比较多的情况下，因为如果乐观锁经常冲突，应用要不断进行重试，反而会降低性能

CAS算法

Compare-and-Swap,即比较并替换，也有叫做Compare-and-set的，比较并设置。
1.比较：读取到一个值A，在将其更新为B之前，检查原值是否为A（未被其他线程改动）
2.设置：如果是，将A更新为B，结束。如果不是，则什么都不做
允许多个线程同时读取（因为没有锁），但是只有一个线程可以成功更新数据，并导致其他要更新数据的线程回滚重试，也叫非阻塞同步（Non-blcking Synchronization）
乐观锁策略也被称为无锁编程。其实，乐观锁并不是“锁”，它仅仅是一个循环重试CAS的算法而已

乐观锁的缺点——ABA问题

如果一个变量V初次读取的时候值为A，并且在准备赋值的时候检查V的值仍然是A，那么我们能说明它的值没有被其他线程修改过吗？很显然，不能。因为在这段时间内其他线程可能将它改为了其他值，又改回了成了A，那CAS操作就会误认为它没有被修改过。这个问题被称为CAS操作的"ABA"问题。

分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的一种方式
分布式锁一般有三种实现方式：

• 数据库乐观锁
• 基于Redis的分布式锁
• 基于ZooKeeper的分布式锁

分布式锁的可靠性需要满足以下四个条件：
1.互斥性。在任意时刻，只有一个客户端能持有锁。
2.不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
3.具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁
4.解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了

使用Redis实现分布式锁原理：

• Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系，基于此，Redis中可以使用SETNX命令实现分布式锁
• SETNX——SET if NOT exists(如果不存在，则设置）

• 若给定的key已经存在，则SETNX不做任何动作；如果需要解锁，使用key命令就能释放锁

  
  image.png