终于懂什么是分布式锁

　　为什么要有分布式锁？
　　模拟一个秒杀接口：
　　商品表：
　　单机情况下，用Jmeter发送1000个请求过来：
　　由于加了sychronized进行方法同步，结果正常。
　　现在模拟集群环境，还是用上面的接口，但启动两个服务，分别是8080和8081端口，用nginx负载均衡到两个tomcat，用Jmeter发送1000个请求到nginx：
　　发现库存并没有-1000，并且控制的库存量打印有重复。
　　结论:
　　我们在系统中修改已有数据时，需要先读取，然后进行修改保存，此时很容易遇到并发问题。由于修改和保存不是原子操作，在并发场景下，部分对数据的操作可能会丢失。在单服务器系统我们常用本地锁来避免并发带来的问题，然而，当服务采用集群方式部署时，本地锁无法在多个服务器之间生效，这时候保证数据的一致性就需要分布式锁来实现。 MySql分布式锁
　　基于数据库的分布式锁, 常用的一种方式是使用表的唯一约束特性。当往数据库中成功插入一条数据时, 代表只获取到锁。将这条数据从数据库中删除，则释放锁。  CREATE TABLE `database_lock` (     `id` BIGINT NOT NULL AUTO_INCREMENT,     `resource` varchar(1024) NOT NULL DEFAULT ＂＂ COMMENT ＂资源＂,     `lock_id` varchar(1024) NOT NULL DEFAULT ＂＂ COMMENT ＂唯一锁编码＂，     `count` int(11) NOT NULL DEFAULT ＂0＂ COMMENT ＂锁的次数，可重入锁＂,     PRIMARY KEY (`id`),     UNIQUE KEY `uiq_lock_id` (`lock_id`)  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=＂数据库分布式锁表＂;
　　当我们想要获得锁时，可以插入一条数据
　　INSERT INTO database_lock(resource,lock_id,count) VALUES (＂resource＂,＂lock_id＂,1);
　　注意：在表database_lock中，lock_id字段做了唯一性约束，可以是机器的mac地址+线程编号,这样如果有多个请求同时提交到数据库的话，数据库可以保证只有一个操作可以成功（其它的会报错：ERROR 1062 (23000): Duplicate entry ‘1’ for key ‘uiq_lock_id’），那么我们就可以认为操作成功的那个请求获得了锁。
　　当需要释放锁的时，可以删除这条数据：
　　DELETE FROM database_lock where method_name =＂resource＂ and cust_id = ＂lock_id＂
　　可重入锁:
　　UPDATE database_lock SET count = count + 1 WHERE method_name =＂resource＂ AND cust_id = ＂lock_id＂
　　伪代码:public void test(){     String resource = ＂resource＂;  String lock_id = ＂lock_id＂;  if(!checkReentrantLock(resource,lock_id)){         lock(resource,lock_id);//加锁  }else{         reentrantLock(resource,lock_id); //可重入锁+1  }     //业务处理  unlock(resource,lock_id);//释放锁 }
　　这种实现方式非常的简单，但是需要注意以下几点：这种锁没有失效时间，一旦释放锁的操作失败就会导致锁记录一直在数据库中，其它线程无法获得锁。这个缺陷也很好解决，比如可以做一个定时任务去定时清理。这种锁的可靠性依赖于数据库。建议设置备库，避免单点，进一步提高可靠性。这种锁是非阻塞的，因为插入数据失败之后会直接报错，想要获得锁就需要再次操作。如果需要阻塞式的，可以弄个for循环、while循环之类的，直至INSERT成功再返回。这种锁也是非可重入的，因为同一个线程在没有释放锁之前无法再次获得锁，因为数据库中已经存在同一份记录了。想要实现可重入锁，可以在数据库中添加一些字段，比如获得锁的主机信息、线程信息等，那么在再次获得锁的时候可以先查询数据，如果当前的主机信息和线程信息等能被查到的话，可以直接把锁分配给它。Redis分布式锁
　　Redis 锁主要利用 Redis 的 setnx 命令。加锁命令：SETNX key value，当键不存在时，对键进行设置操作并返回成功，否则返回失败。KEY 是锁的唯一标识，一般按业务来决定命名。解锁命令：DEL key，通过删除键值对释放锁，以便其他线程可以通过 SETNX 命令来获取锁。锁超时：EXPIRE key timeout, 设置 key 的超时时间，以保证即使锁没有被显式释放，锁也可以在一定时间后自动释放，避免资源被永远锁住。if (setnx(key, 1) == 1){     expire(key, 30)     try {         //TODO 业务逻辑     } finally {         del(key)     } }
　　使用SpingBoot集成Redis后使用分布式锁：
　　可以看到打印的日志不再有重复的库存量，最小的库存量与数据库中的一致。
　　Redis分布式锁可能存在一些问题：
　　1.设置过期时间
　　A客户端获取锁成功，但是在释放锁之前崩溃了，此时该客户端实际上已经失去了对公共资源的操作权，但却没有办法请求解锁（删除 Key-Value 键值对），那么，它就会一直持有这个锁，而其它客户端永远无法获得锁。
　　在加锁时为锁设置过期时间，当过期时间到达，Redis 会自动删除对应的 Key-Value，从而避免死锁。
　　2.SETNX 和 EXPIRE 非原子性
　　如果SETNX成功，在设置锁超时时间之前，服务器挂掉、重启或网络问题等，导致EXPIRE命令没有执行，锁没有设置超时时间变成死锁。Redis 2.6.12 之后 Redis 支持 nx 和 ex 操作是同一原子操作。
　　3.锁误解除
　　如果线程 A 成功获取到了锁，并且设置了过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁；随后 A 执行完成，线程 A 使用 DEL 命令来释放锁，但此时线程 B 加的锁还没有执行完成，线程 A 实际释放的线程 B 加的锁。
　　通过在 value 中设置当前线程加锁的标识，在删除之前验证 key 对应的 value 判断锁是否是当前线程持有。可生成一个 UUID 标识当前线程
　　4.超时解锁导致并发
　　如果线程 A 成功获取锁并设置过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁，线程 A 和线程 B 并发执行。
　　一般有两种方式解决该问题：
　　将过期时间设置足够长，确保代码逻辑在锁释放之前能够执行完成。
　　为获取锁的线程增加守护线程，为将要过期但未释放的锁增加有效时间。
　　更好的方法是是使用Redission，WatchDog机制会为将要过期但未释放的锁增加有效时间。
　　5.redis主从复制
　　A客户端在Redis的master节点上拿到了锁，但是这个加锁的key还没有同步到slave节点，master故障，发生故障转移，一个slave节点升级为master节点，B客户端也可以获取同个key的锁，但客户端A也已经拿到锁了，这就导致多个客户端都拿到锁。
　　使用RedLock
　　首先生成多个Redis集群的Rlock，并将其构造成RedLock。如果循环加锁的过程中加锁失败，那么需要判断加锁失败的次数是否超出了最大值，这里的最大值是根据集群的个数，比如三个那么只允许失败一个，五个的话只允许失败两个，要保证多数成功。加锁的过程中需要判断是否加锁超时，有可能我们设置加锁只能用3ms，第一个集群加锁已经消耗了3ms了。那么也算加锁失败。2，3步里面加锁失败的话，那么就会进行解锁操作，解锁会对所有的集群在请求一次解锁。
　　可以看见RedLock基本原理是利用多个Redis集群，用多数的集群加锁成功，减少Redis某个集群出故障，造成分布式锁出现问题的概率。ZooKeeper分布式锁
　　1.多个客户端创建一个锁节点下的一个接一个的临时顺序节点
　　2.如果自己是第一个临时顺序节点，那么这个客户端加锁成功；如果自己不是第一个节点，就对自己上一个节点加监听器
　　3.当某个客户端监听到上一个节点释放锁，自己就排到前面去了，此时继续执行步骤2，相当于是一个排队机制。
　　使用Curator框架进行加锁和释放锁
　　来源：
　　https://segmentfault.com/a/1190000038330434