分布式锁简单入门以及三种实现方式介绍

不少小伙伴在学习Java的时候，老是感受Java多线程在实际的业务中不多使用，以致于不会花太多的时间去学习，技术债不断累积！等到了必定程度的时候对于与Java多线程相关的东西就很难理解，今天须要探讨的东西也是同样的和Java多线程相关的！作好准备，立刻开车！

学过Java多线程的应该都知道什么是锁，没学过的也不用担忧，Java中的锁能够简单的理解为多线程状况下访问临界资源的一种线程同步机制。

在学习或者使用Java的过程当中进程会遇到各类各样的锁的概念：公平锁、非公平锁、自旋锁、可重入锁、偏向锁、轻量级锁、重量级锁、读写锁、互斥锁等。

蒙了吗？没关系！即便你这些都不会也没关系，由于这个和今天要探讨的关系不大，不过若是你做为一个爱学习的小伙伴，这里也给你准备了一份秘籍：《Java多线程核心技术》，一共19篇祝你一臂之力！免费版的不过瘾，固然也有收费版的！

1、为何要使用分布式锁
咱们在开发应用的时候，若是须要对某一个共享变量进行多线程同步访问的时候，可使用咱们学到的Java多线程的18般武艺进行处理，而且能够完美的运行，毫无Bug！

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

后来业务发展，须要作集群，一个应用须要部署到几台机器上而后作负载均衡，大体以下图：

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

若是咱们业务中确实存在这个场景的话，咱们就须要一种方法解决这个问题！

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

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

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

3、分布式锁的三种实现方式
目前几乎不少大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉咱们“任何一个分布式系统都没法同时知足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时知足两项。”因此，不少系统在设计之初就要对这三者作出取舍。在互联网领域的绝大多数的场景中，都须要牺牲强一致性来换取系统的高可用性，系统每每只须要保证“最终一致性”，只要这个最终时间是在用户能够接受的范围内便可。

在不少场景中，咱们为了保证数据的最终一致性，须要不少的技术方案来支持，好比分布式事务、分布式锁等。有的时候，咱们须要保证一个方法在同一时间内只能被同一个线程执行。

基于数据库实现分布式锁； 
基于缓存（Redis等）实现分布式锁； 
基于Zookeeper实现分布式锁；

尽管有这三种方案，可是不一样的业务也要根据本身的状况进行选型，他们之间没有最好只有更适合！

4、基于数据库的实现方式
基于数据库的实现方式的核心思想是：在数据库中建立一个表，表中包含方法名等字段，并在方法名字段上建立惟一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。

（1）建立一个表：

DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL COMMENT '锁定的方法名',
  `desc` varchar(255) NOT NULL COMMENT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';
1
2
3
4
5
6
7
8
9

（2）想要执行某个方法，就使用这个方法名向表中插入数据：

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '测试的methodName');
1
由于咱们对method_name作了惟一性约束，这里若是有多个请求同时提交到数据库的话，数据库会保证只有一个操做能够成功，那么咱们就能够认为操做成功的那个线程得到了该方法的锁，能够执行方法体内容。

（3）成功插入则获取锁，执行完成后删除对应的行数据释放锁：

delete from method_lock where method_name ='methodName';
1
注意：这只是使用基于数据库的一种方法，使用数据库实现分布式锁还有不少其余的玩法！

使用基于数据库的这种实现方式很简单，可是对于分布式锁应该具有的条件来讲，它有一些问题须要解决及优化：

一、由于是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能，因此，数据库须要双机部署、数据同步、主备切换；

二、不具有可重入的特性，由于同一个线程在释放锁以前，行数据一直存在，没法再次成功插入数据，因此，须要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；

三、没有锁失效机制，由于有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，因此，须要在表中新增一列，用于记录失效时间，而且须要有定时任务清除这些失效的数据；

四、不具有阻塞锁特性，获取不到锁直接返回失败，因此须要优化获取逻辑，循环屡次去获取。

五、在实施的过程当中会遇到各类不一样的问题，为了解决这些问题，实现方式将会愈来愈复杂；依赖数据库须要必定的资源开销，性能问题须要考虑。

5、基于Redis的实现方式
一、选用Redis实现分布式锁缘由：

（1）Redis有很高的性能； 
（2）Redis命令对此支持较好，实现起来比较方便

二、使用命令介绍：

（1）SETNX

SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不作，返回0。
1
（2）expire

expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
1
（3）delete

delete key：删除key
1
在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。

三、实现思想：

（1）获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，经过此在释放锁的时候进行判断。

（2）获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。

（3）释放锁的时候，经过UUID判断是否是该锁，如果该锁，则执行delete进行锁释放。

四、 分布式锁的简单实现代码：

/**
 * 分布式锁的简单实现代码
 * Created by liuyang on 2017/4/20.
 */
public class DistributedLock {

    private final JedisPool jedisPool;

    public DistributedLock(JedisPool jedisPool) {
        this.jedisPool = jedisPool;
    }

    /**
     * 加锁
     * @param lockName       锁的key
     * @param acquireTimeout 获取超时时间
     * @param timeout        锁的超时时间
     * @return 锁标识
     */
    public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
        Jedis conn = null;
        String retIdentifier = null;
        try {
            // 获取链接
            conn = jedisPool.getResource();
            // 随机生成一个value
            String identifier = UUID.randomUUID().toString();
            // 锁名，即key值
            String lockKey = "lock:" + lockName;
            // 超时时间，上锁后超过此时间则自动释放锁
            int lockExpire = (int) (timeout / 1000);

            // 获取锁的超时时间，超过这个时间则放弃获取锁
            long end = System.currentTimeMillis() + acquireTimeout;
            while (System.currentTimeMillis() < end) {
                if (conn.setnx(lockKey, identifier) == 1) {
                    conn.expire(lockKey, lockExpire);
                    // 返回value值，用于释放锁时间确认
                    retIdentifier = identifier;
                    return retIdentifier;
                }
                // 返回-1表明key没有设置超时时间，为key设置一个超时时间
                if (conn.ttl(lockKey) == -1) {
                    conn.expire(lockKey, lockExpire);
                }

                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retIdentifier;
    }

    /**
     * 释放锁
     * @param lockName   锁的key
     * @param identifier 释放锁的标识
     * @return
     */
    public boolean releaseLock(String lockName, String identifier) {
        Jedis conn = null;
        String lockKey = "lock:" + lockName;
        boolean retFlag = false;
        try {
            conn = jedisPool.getResource();
            while (true) {
                // 监视lock，准备开始事务
                conn.watch(lockKey);
                // 经过前面返回的value值判断是否是该锁，如果该锁，则删除，释放锁
                if (identifier.equals(conn.get(lockKey))) {
                    Transaction transaction = conn.multi();
                    transaction.del(lockKey);
                    List<Object> results = transaction.exec();
                    if (results == null) {
                        continue;
                    }
                    retFlag = true;
                }
                conn.unwatch();
                break;
            }
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retFlag;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
五、测试刚才实现的分布式锁

例子中使用50个线程模拟秒杀一个商品，使用–运算符来实现商品减小，从结果有序性就能够看出是否为加锁状态。

模拟秒杀服务，在其中配置了jedis线程池，在初始化的时候传给分布式锁，供其使用。

/**
 * Created by liuyang on 2017/4/20.
 */
public class Service {

    private static JedisPool pool = null;

    private DistributedLock lock = new DistributedLock(pool);

    int n = 500;

    static {
        JedisPoolConfig config = new JedisPoolConfig();
        // 设置最大链接数
        config.setMaxTotal(200);
        // 设置最大空闲数
        config.setMaxIdle(8);
        // 设置最大等待时间
        config.setMaxWaitMillis(1000 * 100);
        // 在borrow一个jedis实例时，是否须要验证，若为true，则全部jedis实例均是可用的
        config.setTestOnBorrow(true);
        pool = new JedisPool(config, "127.0.0.1", 6379, 3000);
    }

    public void seckill() {
        // 返回锁的value值，供释放锁时候进行判断
        String identifier = lock.lockWithTimeout("resource", 5000, 1000);
        System.out.println(Thread.currentThread().getName() + "得到了锁");
        System.out.println(--n);
        lock.releaseLock("resource", identifier);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
模拟线程进行秒杀服务：

public class ThreadA extends Thread {
    private Service service;

    public ThreadA(Service service) {
        this.service = service;
    }

    @Override
    public void run() {
        service.seckill();
    }
}

public class Test {
    public static void main(String[] args) {
        Service service = new Service();
        for (int i = 0; i < 50; i++) {
            ThreadA threadA = new ThreadA(service);
            threadA.start();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
结果以下，结果为有序的：

若注释掉使用锁的部分：

public void seckill() {
    // 返回锁的value值，供释放锁时候进行判断
    //String indentifier = lock.lockWithTimeout("resource", 5000, 1000);
    System.out.println(Thread.currentThread().getName() + "得到了锁");
    System.out.println(--n);
    //lock.releaseLock("resource", indentifier);
}
1
2
3
4
5
6
7
从结果能够看出，有一些是异步进行的：

五、基于ZooKeeper的实现方式
ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个惟一文件名。基于ZooKeeper实现分布式锁的步骤以下：

（1）建立一个目录mylock； 
（2）线程A想获取锁就在mylock目录下建立临时顺序节点； 
（3）获取mylock目录下全部的子节点，而后获取比本身小的兄弟节点，若是不存在，则说明当前线程顺序号最小，得到锁； 
（4）线程B获取全部节点，判断本身不是最小节点，设置监听比本身次小的节点； 
（5）线程A处理完，删除本身的节点，线程B监听到变动事件，判断本身是否是最小的节点，若是是则得到锁。

这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。

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

缺点：由于须要频繁的建立和删除节点，性能上不如Redis方式。

六、总结
上面的三种实现方式，没有在全部场合都是完美的，因此，应根据不一样的应用场景选择最适合的实现方式。

在分布式环境中，对资源进行上锁有时候是很重要的，好比抢购某一资源，这时候使用分布式锁就能够很好地控制资源。 
固然，在具体使用中，还须要考虑不少因素，好比超时时间的选取，获取锁时间的选取对并发量都有很大的影响，上述实现的分布式锁也只是一种简单的实现，主要是一种思想，以上包括文中的代码可能并不适用于正式的生产环境，只作入门参考！

参考文章：

一、https://yq.aliyun.com/articles/60663

二、http://www.hollischuang.com/archives/1716