分布式锁知识总结
为什么要用分布式锁？
在单体架构中，我们可以通过sychronized来保证并发安全，但是在分布式架构中，sychronized没用，sychronized只能保证一个进程（JVM）中的线程安全，无法跨进程
分布式锁的执行流程
分布式锁的实现方式
1、redis实现分布式锁
最简单的redis实现就是通过 redis的setnx（set if not exists）命令来实现
RedisTemplate对redis进行了封装，使用redistemplate就能实现 redis的setnx（set if not exists）命令
bool result = stringRedisTemplate.opsForValue().setIfAbsent( "key","value" )； // setIfAbsent方法就相当于 setnx命令
setIfAbsent方法 返回 true 说明key不存在，插入数据成功
setIfAbsent方法 返回 true 说明key已经存在了，插入数据失败
大概的代码逻辑就是
bool result = stringRedisTemplate.opsForValue().setIfAbsent( "key","value" )； // 设置key（相当于竞争锁 ）
if(!result){
return "key已经存在";
}
执行业务逻辑代码（比如扣库存）
stringRedisTemplate.delete("key"); // 删除key （相当于释放锁）
想想这里面可能出现的问题：
1、线程在运行业务代码的时候出现异常，那么此时就无法释放锁，就会形成死锁。怎么办？ =====》try finally ，在finally中执行delete操作
2、线程在执行业务代码的时候，服务器宕机了，此时也无法释放锁，也会形成死锁。怎么办？ =====》 给 锁的key设置一个timeout
int timeout = 10;
stringRedisTemplate.expire("key",timeout ,TimeUnit.SECONDS);
3、此时加锁与设置timeout之间是有时间损耗的，也就是说如果线程在加完锁正准备设置timeout时，此时服务宕机了，timeout就设置不了，就跟上面情况类似了，也会产生死锁，怎么办？ ================》 保证 加锁与设置timeout 的原子性 （ RedisTemplate 提供了一个重载的setIfAbsent方法来保证原则性，此方法底层就是使用了lua脚本）
redis会将lua脚本中所有的命令当作一个原子操作执行
int timeout = 10;
// bool result = stringRedisTemplate.opsForValue().setIfAbsent( "key","value" )；
// stringRedisTemplate.expire("key",timeout ,TimeUnit.SECONDS);
bool result = stringRedisTemplate.opsForValue().setIfAbsent( "key","value" ,timeout ,TimeUnit.SECONDS)； // 这行代码就相当于把上面两行代码进行了原子性操作
4、线程 1 还没执行完业务代码，此时锁timeout了，redis把线程1 加的锁删了 ，此时线程 2 过来了加了锁，然后执行业务代码，注意！ 此时线程 1 和线程 2 可能同时操作共享资源 ，然后线程1 此时执行完了删锁，注意！ 此时线程 1 删除的锁是线程 2 加的锁，然后此时线程 3过来了加了锁，然后执行业务代码 ，注意！ 此时线程 2 和线程 3可能同时操作共享资源，然后线程2 此时执行完了删锁，注意！ 此时线程2 删除的锁是线程 3 加的锁，......往复循环 ，导致锁永久失效。
怎么办？=====》给自己加的锁 加一个标识，这个标识只有自己知道，此时锁就只能自己释放，别人就释放不了了
5、线程 1 还没执行完业务代码，此时锁timeout了，redis把线程1 加的锁删了 ，此时线程 2 过来了加了锁，然后执行业务代码，注意！ 此时线程 1 和线程 2 可能同时操作共享资源 ，然后线程1 此时执行完了业务代码之后删锁，哦吼，我的锁怎么没了，然后就报错了。怎么办？
======》加大timeout的值
=======》但是有个问题，timeout越大 ====== 》 服务宕机之后，死锁时间越长 =======》其他线程等待的时间越长 ======》用户的脾气越大。 怎么办？
======》开启一个异步线程，开启一个定时任务，每个 1/3 timeout扫描一次，看看当前锁的key 还在不在，当前线程还在不在，是不是死（宕机 ）了，然后线程还在，锁的key也还在，那么就给锁续命，重新设置锁的key 的 timeout ，只要线程没执行完就给锁的key续命，知道线程执行完自动删除锁的key（释放锁）
此时就不得不介绍一个神奇的框架了 ！！！！redisson框架
redisson框架 ---- 一个 redis java client
redisson框架 中解决了上面，底层就是用的setnx ，lua脚本保证原子性，锁的key默认timeout 30s ，其他线程自旋 ， 用timerTask 定时任务 默认 每隔 1/3 timeout 续命一次。
redisson分布式锁实现原理：
redisson框架 使用如下：
6、如果redis用了集群（一主多从），线程 1 的锁的key刚把锁的key存入redis中， redis的master 主节点挂了，锁的key还没同步到slave从节点，然后此时slave从节点升为 master主节点，但是此时这个新的master主节点中没有线程 1 的锁的key ，但是此时线程 1 还在执行业务代码，然后才是 线程 2 来了，由于此时新的master主节点上没有锁的key，所以线程2申请锁成功，然后此时线程 1 和 线程 2 就可能同时访问并使用共享资源 。 此时就有问题了呀！ 怎么办？
=======》①用zookeeper 有延时 ，要同步半数以上的follower才能加锁成功，所以此时不用担心leader挂了，follower中没有锁的key ②人工补偿 ③redis自己解决 用redlock
redlock 实现原理
大概就是搞多个对等的redis节点，节点之间没有依赖（主从依赖），通过 setnx命令 加锁 ，同时发给每个redis节点，发送的这些节点中要有半数以上的redis节点加锁成功，才算认为线程拿到了锁，才继续往下执行业务。（原理跟zookeeper类似 ， 牺牲了性能，如果没超过半数，涉及到锁回滚问题）
7、高并发性下请求到了redis，但是redis是单线程工作模式，在redis中就也不是并发执行，而是串行执行，影响性能。怎么办？
====》 用库存举例， 将库存分段存储，分段加锁=======》把每段的锁的key放到redis集群中，把不同锁的key放到不同的redis master主节点上
一个段的库存不够减怎么办？去减下面段的，合并几个段一起扣减。
2、zookeeper实现分布式锁
由于zookeeper上面的临时节点是唯一的，只会创建一个，而锁也只有一把，所以它能代表这个锁，多个客户端去抢这个锁，也就是去zookeeper上面创建临时节点，看谁创建的快，谁第一个创建了这个临时节点谁就获取到了锁。
此时clientA第一个成功创建了临时节点，就代表clientA已经获取到了锁，其他client再去创建这个临时节点，发现这个节点已经存在了，他们就不能去创建了，就都阻塞了，他们一直监听这个节点的变化，也就是在监听这个锁的变化（通过zookeeper Watch功能）
clientA完成了它的业务操作 ，结束了与zookeeper的会话 临时节点被自动删除，就代表释放了锁，此时其他client监听到了临时节点被删除了（锁释放了），就都会去竞争锁，也就是去创建临时节点。
同一时间有多个客户端在竞争锁
======》上面这个实现方式有什么问题呢 ？想想如果上千个client去监听这个临时节点的变化，一旦这个临时节点变化了，然后此时就是上千个client去竞争这个锁（羊群效应 / 惊群效应），这对于zookeeper的压力是非常大的，所以这个方案不可行。那怎么办呢？
======》使用临时顺序节点 + 监听
使用临时顺序节点创建出来的节点都是有序的，只有最小的节点能拿到锁，其他的节点监听比它小的前一个节点。
获取锁大概流程： 每个client 分别 创建临时顺序节点，然后谁的节点最小就谁能拿到锁，其他节点就监听比自己小的前一个节点
比如下图：A B C D分别创建节点，A最先创建，所以它的节点编号最小，所以它能获取锁，然后B监听A，C监听B，D监听C
释放锁大概流程：clientA 执行完自己的业务之后结束了与zookeeper的会话，会话一结束，节点会自动删除（释放了锁），同时clientB监听到了clientA的这个节点被删除后，会去判断自己的节点是不是最小的节点，如果是最小的就获取锁，如果不是就继续监听等待，不做任务处理，clientA节点删除只对clientB有影响，对后面的 C D 等节点没有影响，因为C只监听B，B是没有变化的，所以C不会受到影响，不会变，D只监听C，C没有变，D也不会有影响，也不会变.......就解决的羊群（惊群）效应。
同一时间只有一个客户端在竞争锁
大概流程： 自己看图 ， 直接通过 curator框架就可以实现， curator已经将这些问题解决了，封装好了，直接用就行。
3、数据库实现分布式锁
基于数据库表（主要原理：数据库的主键不能重复，作为分布式锁的实现）
0、首先先创建一个tb_lock表，用于记录当前哪个线程正在使用数据，表里就一个 业务ID 或者业务名称 字段 （唯一主键），当作锁
1、当线程要访问数据时，会先将要执行的业务的业务id或者业务名称 ，insert插入tb_lock表中
2、当插入成功，代表该线程获得了锁，即可执行业务逻辑
3、当其他线程在执行相同业务的时候也会先将要执行业务的 业务id或者业务名称 插入tb_lock表中，由于主键冲突，此时会导致插入失败，就代表获取锁失败
4、获取锁成功的线程在执行完业务代码后，在删除tb_lock表中删除对应业务的 业务id或者业务名称 ，代表释放锁
想想这样实现会出现问题吗？
1、一旦数据库挂掉，会导致业务系统不可用。
====》用两个数据库，一主一从，数据之前双向同步。一旦挂掉快速切换到备库上。
2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
====》做一个异步定时任务，每隔一定时间把数据库中的超时数据清理一遍。
3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
====》用while循环，直到insert成功再返回成功。
4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
====》在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
基于数据库表的排它锁实现（基于MySql的InnoDB引擎）
1、在执行业务逻辑之前，先通过一个带有for update 的查询语句 拿到排它锁
select * from table where productId = 1 for update
行锁 ： 当前连接要执行的带有 for update 的SQL语句以后，指定了主键查询，代表当前连接锁定了这条数据（productId = 1）
select * from table for update
表锁：当前连接执行带有for update的SQL语句以后，没有指定主键查询，那么会将表进行锁定，只有当前连接可以对这张表进行操作
2、获得排它锁的线程即可获得分布式锁，执行业务逻辑
3、执行完业务逻辑之后，再通过JDBC的connection.commit() 方法来释放锁
想想这样实现会出现问题吗？
1、一旦数据库挂掉，会导致业务系统不可用。
====》使用这种方式，此问题不会发生，服务宕机之后数据库会自己把锁释放掉。
2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
====》做一个异步定时任务，每隔一定时间把数据库中的超时数据清理一遍。
3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
====》使用这种方式，此问题不会发生，for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
====》在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。