分布式锁

一 . 为什么要用分布式锁

我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！

注意这是单机应用，也就是所有的请求都会分配到当前服务器的JVM内部，然后映射为操作系统的线程进行处理！而这个共享变量只是在这个JVM内部的一块内存空间！

后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图：

　　上图可以看到，变量A存在JVM1、JVM2、JVM3三个JVM内存中(这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象，例如：UserController控制器中的一个整形类型的成员变量)，如果不加任何控制的话，变量A同时都会在JVM分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同JVM内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的！

如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题！为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。在单机环境中，Java中提供了很多并发处理相关的API。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

二 .分布式锁应该具备哪些条件

在分析分布式锁的三种实现方式之前，先了解一下分布式锁应该具备哪些条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行； 2、高可用的获取锁与释放锁； 3、高性能的获取锁与释放锁； 4、具备可重入特性； 5、具备锁失效机制，防止死锁； 6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

三、分布式锁的三种实现方式

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

3.1 基于数据库实现排他锁

方案1

表结构：

CREATE TABLE 'METHODLOCK'(
    'id' int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
    'method_name' varchar(64) not null default '' comment '锁定的方法名',
    'remark' varchar(1024) not null default '备注信息',
    'update_time' timestamp not null default current_timestamp on update current_timestamp commnet '保存数据时间，自动生成'
)

　　获取锁的方法：直接往表里插入一条当前方法的记录，我们也对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功。

方案2

在原先表结构的基础上再加上一个版本号。这样如果想获取锁，就先先获取锁的信息

 select id, method_name, state,version from method_lock where state=1 and method_name='methodName';

占有锁:

update t_resoure set state=2, version=2, update_time=now() where method_name='methodName' and state=1 and version=2;

如果没有更新影响到一行数据，则说明这个资源已经被别人占位了。

缺点：

1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。 2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。 3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。 4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据已经存在了。

解决方案： 1、数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。 2、没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。 3、非阻塞的？搞一个while循环，直到insert成功再返回成功。 4、非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。3.2 基于redis实现

获取锁使用命令:

SET resource_name my_random_value NX PX 30000

方案：

try{
    lock = redisTemplate.opsForValue().setIfAbsent(lockKey, LOCK);
    logger.info("cancelCouponCode是否获取到锁："+lock);
    if (lock) {
        // TODO
        redisTemplate.expire(lockKey,1, TimeUnit.MINUTES); //成功设置过期时间
        return res;
    }else {
        logger.info("cancelCouponCode没有获取到锁，不执行任务!");
    }
}finally{
    if(lock){    
        redisTemplate.delete(lockKey);
        logger.info("cancelCouponCode任务结束，释放锁!");        
    }else{
        logger.info("cancelCouponCode没有获取到锁，无需释放锁!");
    }
}

缺点：

在这种场景(主从结构)中存在明显的竞态: 客户端A从master获取到锁， 在master将锁同步到slave之前，master宕掉了。 slave节点被晋级为master节点， 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。安全失效！

3.3 基于zookeeper实现

待补充

四.总结

下面的表格总结了Zookeeper和Redis分布式锁的优缺点：

三种方案的比较

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

从理解的难易程度角度(从低到高)

数据库 > 缓存 > Zookeeper

从实现的复杂性角度(从低到高)

Zookeeper >= 缓存 > 数据库

从性能角度(从高到低)

缓存 > Zookeeper >= 数据库

从可靠性角度(从高到低)

Zookeeper > 缓存 > 数据库

上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。
从理解的难易程度角度(从低到高)
数据库 > 缓存 > Zookeeper
从实现的复杂性角度(从低到高)
Zookeeper >= 缓存 > 数据库
从性能角度(从高到低)
缓存 > Zookeeper >= 数据库
从可靠性角度(从高到低)
Zookeeper > 缓存 > 数据库