多种分布式锁该怎么选？

首先咱们看下什么是锁

普通的锁，即在单机多线程环境下，当多个线程需要访问同一个变量或代码片段时，被访问的变量或代码片段叫做临界区域，我们需要控制线程一个一个的顺序执行，否则会出现并发问题。

如何控制呢？就是设置一个各个线程都能看的见的标志。然后，每个线程想访问临界区域时，都要先查看标志，如果标志没有被占用，则说明目前没有线程在访问临界区域。如果标志被占用了，则说明目前有线程正在访问临界区域，则当前线程需要等待。这个标志，就是锁。

在单机多线程的java程序中，我们可以使用堆内存中的变量作为标志，因为多线程是共享堆内存的，堆内存中的变量对于各个线程都是可见的。

接下来，我们来看什么是分布式锁。

在分布式环境下，即多台计算机，每个计算机上会启动jvm执行程序的运行环境下，如果不同计算机上的线程想访问临界区域时，该怎么办呢？

前面普通锁的使用堆内存中的变量的方式肯定不适用了。因为在多机环境下，某台计算机上的堆内存中的变量对于其他计算机上的线程肯定是不可见的。那么，根据锁的本质和原理，我们就要找到另外的对于多机上的线程都可见的标志，以它来作为锁，就可以了。这样的锁，就是分布式锁。

场景及实现方式

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。

针对分布式锁的实现，目前比较常用的有以下三种方案：

基于数据库实现分布式锁；

基于缓存（Redis等）实现分布式锁；

基于Zookeeper实现分布式锁；

在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理）

可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。

这把锁要是一把可重入锁（避免死锁）

这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）

有高可用的获取锁和释放锁功能

获取锁和释放锁的性能要好

三种方案的比较

上面三种种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。

基于数据库实现分布式锁

缺点：

1.db操作性能较差，并且有锁表的风险

2.非阻塞操作失败后，需要轮询，占用cpu资源;

3.长时间不commit或者长时间轮询，可能会占用较多连接资源

基于缓存（Redis等）实现分布式锁

缺点：

1.锁删除失败 过期时间不好控制

2.非阻塞，操作失败后，需要轮询，占用cpu资源;

基于Zookeeper实现分布式锁

缺点：性能不如redis实现，主要原因是写操作（获取锁释放锁）都需要在Leader上执行，然后同步到follower。

从理解的难易程度角度（从低到高）

数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）

Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）

缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）

Zookeeper > 缓存 > 数据库