分布式锁的实现

前言

我们在开发应用时，如果需要对一个共享变量进行多线程同步访问的时候，我们可以使用Java多线程的各个技能点来处理，保证完美运行无BUG。
但是这里的都只是单机应用，即在同一个JVM中；然后随着业务发展、微服务化，一个应用需要部署到多台服务器上然后做负载均衡，大概的架构图如下：


集群模式下的负载均衡

在上图可以看到，变量A在JVM1、JVM2、JVM3三个JVM内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果我们不加任何控制的话，变量A同进都会在JVM分配一块内存，三个请求发过来同时对这个变量进行操作，显然结果不是我们想要的。

如果我们业务中存在这样的场景的话，就需要找到一种方法来解决。

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

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

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

分布式锁的实现方式

目前几乎所有大型网站及应用都是分布式部署，分布式场景中的数据一致性问题一直是一个比较重要的话题，分布式的CAP理论告诉我们任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）,最多只能同时满足两项。
一般情况下，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性，只要这个最终时间是在用户可以接受的范围内即可。
在很多时候，为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一信方法在同一时间内只能被同一个线程执行。
而分布式锁的具体实现方案有如下三种：

基于数据库实现；
基于缓存（Redis等）实现；
基于Zookeeper实现；

以上尽管有三种方案，但是我们需要根据不同的业务进行选型。

基于数据库的实现方式

基于数据库的实现方式的思想核心为：

在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。

一、创建一个表

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 = '锁定中的方法';

二、想要执行某个方法，就使用这个方法名向表中插入数据

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '测试的methodName');

由于我们对method_name做了唯一性约束，如果有多个请求同时提交插入操作时，数据库能确保只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体中的内容。

三、执行完成后，删除对应的行数据释放锁

delete from method_lock where method_name ='methodName';

这里只是基于数据库实现的一种方法（比较粗的一种）。
但是对于分布式锁应该具备的条件来说，还有一些问题需要解决及优化：

  • 因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能。所以，数据库需要双机部署、数据同步、主备切换；
  • 它不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据。所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器线程相同，若相同则直接获取锁。
  • 没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；
  • 不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取；
  • 依赖数据库需要一定的资源开销，性能问题需要考虑；

基于缓存（Redis）的实现方式

使用Redis实现分布式锁的理由：

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

Redis命令介绍：

SETNX

// 当且仅当key不存在时，set一个key为val的字符串，返回1；
// 若key存在，则什么都不做，返回0。
SETNX key val;

expire

// 为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
expire key timeout;

delete

// 删除key
delete key;

我们通过Redis实现分布式锁时，主要通过上面的这三个命令。

通过Redis实现分布式的核心思想为：

  1. 获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间自动释放锁，锁的value值为一个随机生成的UUID，通过这个value值，在释放锁的时候进行判断。
  2. 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
    3.释放锁的时候，通过UUID判断是不是当前持有的锁，若时该锁，则执行delete进行锁释放。

具体实现代码如下：

public class DistributedLock {

    private final JedisPool jedisPool;
    private final static String KEY_PREF = "lock:"; // 锁的前缀

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

    /**
     * 加锁
     *
     * @param lockName       String 锁的名称(key)
     * @param acquireTimeout long 获取超时时间
     * @param timeout        long 锁的超时时间
     * @return 锁标识
     */
    public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
        Jedis conn = null;

        try {
            // 获取连接
            conn = jedisPool.getResource();
            // 随机生成一个value
            String identifier = UUID.randomUUID().toString();
            // 锁名,即 key值
            String lockKey = KEY_PREF + 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值,用于释放锁时间确认
                    return identifier;
                }

                // 返回-1代表key没有设置超时时间,为key设置一个超时时间
                if (conn.ttl(lockKey) == -1) {
                    conn.expire(lockKey, lockExpire);
                }

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

    /**
     * 释放锁
     *
     * @param lockName   String 锁key
     * @param identifier String 释放锁的标识
     * @return boolean
     */
    public boolean releaseLock(String lockName, String identifier) {
        Jedis conn = null;
        String lockKey = KEY_PREF + 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 (Exception e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retFlag;
    }
}

基于Zookeeper的实现方式

基于Zookeeper临时有序节点同样可以实现分布式锁。
大致思想为：

每个客户端对某个方法加锁时，在zookeeper上的该方法对应的指定节点目录下，生成一个唯一的瞬时有序节点。
判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。如果获取到比自己小的兄弟节点不存在，则说明当前线程顺序号最小，获得锁。
如果判断自己不是那最小的一个节点，则设置监听比自己次小的节点；
如果已处理完成，则删除自己的节点。

优点
具备高可用、可重入、阻塞锁特性、可解决失效死锁问题。
缺点
因为需要频繁的创建和删除节点，性能上不如Redis方式。
PS
在这里有一个很好用的Zookeeper客户端开源库Apache Curator

Apache Curator

三种方案的比较

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

数据库 > 缓存 > Zookeeper

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

Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）

缓存 > Zookeeper >= 数据库

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

Zookeeper > 缓存 > 数据库

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 199,393评论 5赞 467
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 83,790评论 2赞 376
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 146,391评论 0赞 330
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 53,703评论 1赞 270
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 62,613评论 5赞 359
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,003评论 1赞 275
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,507评论 3赞 390
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,158评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,300评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2赞 317
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1赞 328
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,984评论 3赞 316
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,569评论 3赞 303
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2赞 345
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2赞 339