分布式锁的类型

　　Java提供了两种内置的锁的实现，一种是由JVM实现的synchronized和JDK提供的Lock，当你的应用是单机或者说单进程应用时，可以使用synchronized或Lock来实现锁。

　　synchronized与RetreenLock区别处：Synchronized是java语言的关键字，是原生语法层面的互斥，需要jvm实现。而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成，ReentrantLock类提供了一些高级功能，主要有：

• 等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。
• 公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。
• 锁绑定多个条件，一个ReentrantLock对象可以同时绑定对个对象。

　　Java中锁的种类有：

• 自旋锁：让当前线程不停地的在循环体内执行实现的，当循环的条件被其他线程改变时 才能进入临界区。由于自旋锁只是将当前线程不停地执行循环体，不进行线程状态的改变，所以响应速度更快。但当线程数不停增加时，性能下降明显，因为每个线程都需要执行，占用CPU时间。如果线程竞争不激烈，并且保持锁的时间段。适合使用自旋锁。
• 阻塞锁：让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间） 时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。
• 重入锁：同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码。java下的ReentrantLock和synchronized都是重入锁。

　　从宏观上分为如下两种：

• 乐观锁：乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。
• 悲观锁：悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会block直到拿到锁。java中的悲观锁就是Synchronized,AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如RetreenLock。　　

但是，当你的应用涉及到多机、多进程共同完成时，例如现在的互联网架构，一般都是分布式的RPC框架来支撑，那么这样你的Server有多个，由于负载均衡的路由规则随机，相同的请求可能会打到不同的Server上进行处理，那么这时候就需要一个全局锁来实现多个线程(不同的进程)之间的同步。

　　实现全局的锁需要依赖一个第三方系统，此系统需要满足高可用、一致性比较强同时能应付高并发的请求。

　　常见的处理办法有三种：数据库、缓存（redis，memcached，tair）、分布式协调系统（Zookeeper）。数据库和缓存是比较常用的，但是分布式协调系统是不常用的。

分布式锁的设计应该是：

• 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
• 这把锁要是一把可重入锁，另外还要具备锁失效机制（避免死锁）
• 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）
• 有高可用的获取锁和释放锁功能
• 获取锁和释放锁的性能要好

------------------------------------------------------------------------

数据库实现：

 利用主键唯一规则（或者利用Mysql行锁的特性）

　　首先我们利用主键唯一规则，在争抢锁的时候向DB中写一条记录，这条记录主要包含锁的id、当前占用锁的线程名、重入的次数和创建时间等，如果插入成功表示当前线程获取到了锁，如果插入失败那么证明锁被其他人占用，等待一会儿继续争抢，直到争抢到或者超时为止。

　　重入主要实现思路是，在每次获取锁之前去取当前锁的信息，如果锁的线程是当前线程，那么更新锁的count+1，并且执行锁之后的逻辑。如果不是当前锁，那么进行重试。释放的时候也要进行count-1，最后减到0时，删除锁标识释放锁。

优点：实现简单

缺点：没有超时保护机制，mysql存在单点，并发量大的时候请求量太大、没有线程唤醒机制，用异常去控制逻辑多少优点恶心。

• 因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换；
• 没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；
• 不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取。

-------------------------------------------------------------------------

缓存分布式锁：
　　缓存实现分布式锁还是比较常见的，因为缓存比较轻量，并且缓存的响应快、吞吐高。最重要的是还有自动失效的机制来保证锁一定能释放。

　　缓存的分布式锁主要通过Redis实现，setNX是Redis提供的一个原子操作，如果指定key存在，那么setNX失败，如果不存在会进行Set操作并返回成功。我们可以利用这个来实现一个分布式的锁，主要思路就是，set成功表示获取锁，set失败表示获取失败，失败后需要重试。

优点：实现简单，吞吐量十分客观，对于高并发情况应付自如，自带超时保护，对于网络抖动的情况也可以利用超时删除策略保证不会阻塞所有流程。

缺点：单点问题、没有线程唤醒机制、网络抖动可能会引起锁删除失败。

---------------------------------------------------------------------------

基于zookeeper：
　　zookeeper是一个分布式一致性协调框架，主要可以实现选主、配置管理和分布式锁等常用功能，因为Zookeeper的写入都是顺序的，在一个节点创建之后，其他请求再次创建便会失败，同时可以对这个节点进行Watch，如果节点删除会通知其他节点抢占锁。步骤：

• 创建一个目录mylock；
• 线程A想获取锁就在mylock目录下创建临时顺序节点；
• 获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
• 线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
• 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

　　Curator是Netflix开源的一套ZooKeeper客户端框架，curator-recipes库里面集成了很多zookeeper的应用场景，因此，需要使用zookeeper的分布式锁功能，可以使用curator-recipes库。

优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。

缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。

参考：

https://juejin.im/post/5a0be84e6fb9a0450b65ec97

https://www.jianshu.com/p/c2b4aa7a12f1