作者：队长给我球。
cnblogs.com/JJJ1990/p/10496850.html
首先，分布式锁的原理和我们平时讲的基本一样。目的是确保当多个线程并发时，只有一个线程同时操作这个业务或方法或变量。
在一个进程中，也就是jvm或应用程序，我们很容易处理控制。在jdk java.util包中，已经为我们提供了Lock这些方法，比如synchronized关键字或者lock lock，这些都是可以处理的。
但是，如果我们当前的应用程序中只部署了一台服务器，那么并发性非常差，如果同时有上万个请求，那么服务器很有可能会不堪重负而瘫痪。
想想11日、30日晚上10: 00支付宝红包等业务场景，自然需要用多台服务器同时处理这些业务，所以可能会有上百个这样的服务同时处理。
但是让我们都想想。如果有100台服务器处理分发红包的业务，现在假设有1亿个红包，1000万人，金额是随机的，那么在这个业务场景下，我们是否要保证这1000万人最终分发的红包之和等于1亿？
如果我们处理不好，每人会得到100万，那么这个胆大的小松鼠的父亲就得在元旦第一天宣布破产。
00-1010首先来说说为什么要集群。简单理解就是需求(并发请求)变大了，一个工人处理能力有限，要多招几个工人一起处理。
假设1000万个请求平均分布在100台服务器上，每台服务器接收10w个请求(这10w个请求不在同一秒钟内到来，但可能在1、2个小时内，我们可以想象我们晚上30点打开红包，10.20开始的时候，有的人马上打开，有的人12点才想起~)
在这种情况下，平均每秒的请求数不到1000个，这种压力还是可以由一般的服务器来承担的。
第一个要求到达后，有必要给他1亿里的一部分钱吗？金额是随机的。假设第一个人得100，有必要从1亿中减去100块，剩下99999900块吗~
第二个用户会再分一次。金额是随机的。这次，它将被分成200块。是不是说剩下的99999900块需要减去200块，剩下9999700块？
10w用户来了，还剩下100W，所以1000w都是他的。
等于每台服务器分1亿，也就是10w用户分1亿，最后总共有100台服务器，需要分100亿。
如果是这样的话，虽然大胆小松鼠的父亲不会破产(根据最新统计，有2300亿元的大胆小松鼠)，那么开发项目组拿着红包和产品经理就可以GG了~
简化结构图如下：
00-1010然后，为了解决这个问题，让1000万用户分成1亿而不是100亿。这时，分布式锁就派上用场了。
分布式锁可以将整个集群视为一个应用程序，所以需要这个锁，独立于每个服务，而不是在服务内部。
假设第一个服务器收到用户1的请求，那么这个时候，他不能只判断自己的应用可以分多少钱，而是需要到外面去问负责管理1亿红包的人(服务)，问他：嘿，我这里要分100块，给我100块。
管理红包的妹子(服务)一看，还有1亿。嗯，这是100元，然后还剩99999900元。
第二个请求到达后，被服务器2获取，并继续询问。管理红包的女生在这里会被分成10块。管理红包的女生先查了一下，还剩9999900块。然后她说：好的，这是10块。剩下99999890美元。
当第1000个请求到达时，服务器100得到请求，继续问，管理红包的妹子，你要100，妹子翻个白眼，告诉你只剩一块了，你要不要爱，那这个时候只能得到一块(一块也是钱，买个辣条就可以了)。
这些请求编号1和2不代表执行顺序。在正式的场景中，100台服务器中的每台服务器都应该持有访问负责红包的姐妹(服务)的请求。然后负责红包的姐姐会同时收到100个请求。这时候你只需要给负责红包的妹子加一把锁(扔绣球)。谁从你的100台服务器上拿到锁(抓住绣球花)，谁就会进来和我说话。
经过以上分布式加锁处理，大胆的小松鼠爸爸终于松了一口气，决定给每个红包团队加一个鸡腿。
简化结构图如下：
00-1010说到分布式锁的实现，还是有很多方法的，比如数据库、redis分布式锁、zookeeper分布式锁等等。
如果我们用redis作为分布式锁，那么上图中负责红包的女生
子（服务）”，就可以替换成redis，请自行脑补。3.1，为什么redis可以实现分布式锁？
首先redis是单线程的，这里的单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
在实际的操作中过程大致是这样子的：
服务器1要去访问发红包的妹子，也就是redis，那么他会在redis中通过"setnx key value" 操作设置一个key 进去，value是啥不重要，重要的是要有一个key，也就是一个标记，而且这个key你爱叫啥叫啥，只要所有的服务器设置的key相同就可以。
假设我们设置一个，如下图
那么我们可以看到会返回一个1，那就代表了成功。
如果再来一个请求去设置同样的key，如下图：
这个时候会返回0，那就代表失败了。
那么我们就可以通过这个操作去判断是不是当前可以拿到锁，或者说可以去访问“负责发红包的妹子”，如果返回1，那我就开始去执行后面的逻辑，如果返回0，那就说明已经被人占用了，我就要继续等待。
当服务器1拿到锁之后，进行了业务处理，完成后，还需要释放锁，如下图所示：
删除成功返回1，那么其他的服务器就可以继续重复上面的步骤去设置这个key，以达到获取锁的目的。
当然以上的操作是在redis客户端直接进行的，通过程序调用的话，肯定就不能这么写，比如java 就需要通过jedis 去调用，但是整个处理逻辑基本都是一样的
通过上面的方式，我们好像是解决了分布式锁的问题，但是想想还有没有什么问题呢？？
对，问题还是有的，可能会有死锁的问题发生，比如服务器1设置完之后，获取了锁之后，忽然发生了宕机。
那后续的删除key操作就没法执行，这个key会一直在redis中存在，其他服务器每次去检查，都会返回0，他们都会认为有人在使用锁，我需要等。
为了解决这个死锁的问题，我们就就需要给key 设置有效期了。
设置的方式有2种
1，第一种就是在set完key之后，直接设置key的有效期 "expire key timeout" ，为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
这种方式相当于，把锁持有的有效期，交给了redis去控制。如果时间到了，你还没有给我删除key，那redis就直接给你删了，其他服务器就可以继续去setnx获取锁。
2，第二种方式，就是把删除key权利交给其他的服务器，那这个时候就需要用到value值了，
比如服务器1，设置了value 也就是 timeout 为 当前时间+1 秒 ，这个时候服务器2 通过get 发现时间已经超过系统当前时间了，那就说明服务器1没有释放锁，服务器1可能出问题了，
服务器2就开始执行删除key操作，并且继续执行setnx 操作。
但是这块有一个问题，也就是，不光你服务器2可能会发现服务器1超时了，服务器3也可能会发现，如果刚好，服务器2，setnx操作完成，服务器3就接着删除，是不是服务器3也可以setnx成功了？
那就等于是服务器2和服务器3都拿到锁了，那就问题大了。这个时候怎么办呢？
这个时候需要用到 “GETSET key value” 命令了。这个命令的意思就是获取当前key的值，并且设置新的值。
假设服务器2发现key过期了，开始调用 getset 命令，然后用获取的时间判断是否过期，如果获取的时间仍然是过期的，那就说明拿到锁了。
如果没有，则说明在服务2执行getset之前，服务器3可能也发现锁过期了，并且在服务器2之前执行了getset操作，重新设置了过期时间。
那么服务器2就需要放弃后续的操作，继续等待服务器3释放锁或者去监测key的有效期是否过期。
这块其实有一个小问题是，服务器3已经修改了有效期，拿到锁之后，服务器2，也修改了有效期，但是没能拿到锁，但是这个有效期的时间已经被在服务器3的基础上有增加一些，但是这种影响其实还是很小的，几乎可以忽略不计。
3.2，为什么zookeeper可以实现分布式锁？
百度百科是这么介绍的：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
那对于我们初次认识的人，可以理解成ZooKeeper就像是我们的电脑文件系统，我们可以在d盘中创建文件夹a，并且可以继续在文件夹a中创建 文件夹a1，a2。
那我们的文件系统有什么特点？？那就是同一个目录下文件名称不能重复，同样ZooKeeper也是这样的。
在ZooKeeper所有的节点，也就是文件夹称作 Znode，而且这个Znode节点是可以存储数据的。
我们可以通过“ create /zkjjj nice” 来创建一个节点，这个命令就表示，在跟目录下创建一个zkjjj的节点，值是nice。同样这里的值，和我在前面说的redis中的一样，没什么意义，你随便给。
另外ZooKeeper可以创建4种类型的节点，分别是：
持久性节点持久性顺序节点临时性节点临时性顺序节点首先说下持久性节点和临时性节点的区别，持久性节点表示只要你创建了这个节点，那不管你ZooKeeper的客户端是否断开连接，ZooKeeper的服务端都会记录这个节点。
临时性节点刚好相反，一旦你ZooKeeper客户端断开了连接，那ZooKeeper服务端就不再保存这个节点。
再说下顺序性节点，顺序性节点是指，在创建节点的时候，ZooKeeper会自动给节点编号比如0000001 ，0000002 这种的。
最后说下，zookeeper有一个监听机制，客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）等，zookeeper会通知客户端。
下面我们继续结合我们上面的分红包场景，描述下在zookeeper中如何加锁。
假设服务器1，创建了一个节点 /zkjjj ,成功了，那服务器1就获取了锁，服务器2再去创建相同的锁，那么他就会失败，这个时候他就就只能监听这个节点的变化。
等到服务器1，处理完业务，删除了节点后，他就会得到通知，然后去创建同样的节点，获取锁处理业务，再删除节点，后续的100台服务器与之类似
注意这里的100台服务器并不是挨个去执行上面的创建节点的操作，而是并发的，当服务器1创建成功，那么剩下的99个就都会注册监听这个节点，等通知，以此类推。
但是大家有没有注意到，这里还是有问题的，还是会有死锁的情况存在，对不对？
当服务器1创建了节点后挂了，没能删除，那其他99台服务器就会一直等通知，那就完蛋了。。。
这个时候呢，就需要用到临时性节点了，我们前面说过了，临时性节点的特点是客户端一旦断开，就会丢失，也就是当服务器1创建了节点后，如果挂了。
那这个节点会自动被删除，这样后续的其他服务器，就可以继续去创建节点，获取锁了。
但是我们可能还需要注意到一点，就是惊群效应：举一个很简单的例子,xydppx往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到..
就是当服务器1节点有变化，会通知其余的99个服务器，但是最终只有1个服务器会创建成功，这样98还是需要等待监听，那么为了处理这种情况，就需要用到临时顺序性节点
大致意思就是，之前是所有99个服务器都监听一个节点，现在就是每一个服务器监听自己前面的一个节点。
假设100个服务器同时发来请求，这个时候会在 /zkjjj 节点下创建 100 个临时顺序性节点 /zkjjj/000000001, /zkjjj/000000002,一直到 /zkjjj/000000100,这个编号就等于是已经给他们设置了获取锁的先后顺序了。
当001节点处理完毕，删除节点后，002收到通知，去获取锁，开始执行，执行完毕，删除节点，通知003~以此类推。