7步搞懂分布式全内容，我不信面试官还敢“怼，作为Java开发程序员-CSDN博客

本文链接：https://blog.csdn.net/2401_83944328/article/details/137211912

本文探讨了基于Redis、Zookeeper以及数据库（如MySQL）实现的分布式锁，包括使用临时节点、乐观锁和悲观锁的原理及示例，强调了在不同场景下的优缺点和注意事项。

摘要由CSDN通过智能技术生成

基于数据的乐观锁实现分布式锁
基于zookeeper临时节点的分布式锁
基于redis的分布式锁

5. redis的分布式锁

获取锁:

在set命令中, 有很多选项可以用来修改命令的行为, 一下是set命令可用选项的基本语法

redis 127.0.0.1:6379>SET KEY VALUE [EX seconds] [PX milliseconds] [NX|XX] - EX seconds 设置指定的到期时间(单位为秒) - PX milliseconds 设置指定的到期时间(单位毫秒) - NX: 仅在键不存在时设置键 - XX: 只有在键已存在时设置

方式1: 推介

private static final String LOCK_SUCCESS = “OK”; private static final String SET_IF_NOT_EXIST = “NX”; private static final String SET_WITH_EXPIRE_TIME = “PX”; public static boolean getLock(JedisCluster jedisCluster, String lockKey, String requestId, int expireTime) { // NX: 保证互斥性 String result = jedisCluster.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); if (LOCK_SUCCESS.equals(result)) { return true; } return false; }

方式2:

public static boolean getLock(String lockKey,String requestId,int expireTime) { Long result = jedis.setnx(lockKey, requestId); if(result == 1) { jedis.expire(lockKey, expireTime); return true; } return false; }

注意: 推介方式1, 因为方式2中setnx和expire是两个操作, 并不是一个原子操作, 如果setnx出现问题, 就是出现死锁的情况, 所以推荐方式1

释放锁:

方式1: del命令实现

public static void releaseLock(String lockKey,String requestId) { if (requestId.equals(jedis.get(lockKey))) { jedis.del(lockKey); }}

方式2: redis+lua脚本实现推荐

public static boolean releaseLock(String lockKey, String requestId) { String script = “if redis.call(‘get’, KEYS[1]) == ARGV[1] then returnredis.call(‘del’, KEYS[1]) else return 0 end”; Object result = jedis.eval(script, Collections.singletonList(lockKey),Collections.singletonList(requestId)); if (result.equals(1L)) { return true;} return false; }

6. zookeeper的分布式锁

6.1 zookeeper实现分布式锁的原理

理解了锁的原理后，就会发现，Zookeeper 天生就是一副分布式锁的胚子。

首先，Zookeeper的每一个节点，都是一个天然的顺序发号器。

在每一个节点下面创建子节点时，只要选择的创建类型是有序（EPHEMERAL_SEQUENTIAL 临时有序或者PERSISTENT_SEQUENTIAL 永久有序）类型，那么，新的子节点后面，会加上一个次序编号。这个次序编号，是上一个生成的次序编号加一

比如，创建一个用于发号的节点“/test/lock”，然后以他为父亲节点，可以在这个父节点下面创建相同前缀的子节点，假定相同的前缀为“/test/lock/seq-”，在创建子节点时，同时指明是有序类型。如果是第一个创建的子节点，那么生成的子节点为/test/lock/seq-0000000000，下一个节点则为/test/lock/seq-0000000001，依次类推，等等。

其次，Zookeeper节点的递增性，可以规定节点编号最小的那个获得锁。

一个zookeeper分布式锁，首先需要创建一个父节点，尽量是持久节点（PERSISTENT类型），然后每个要获得锁的线程都会在这个节点下创建个临时顺序节点，由于序号的递增性，可以规定排号最小的那个获得锁。所以，每个线程在尝试占用锁之前，首先判断自己是排号是不是当前最小，如果是，则获取锁。

第三，Zookeeper的节点监听机制，可以保障占有锁的方式有序而且高效。

每个线程抢占锁之前，先抢号创建自己的ZNode。同样，释放锁的时候，就需要删除抢号的Znode。抢号成功后，如果不是排号最小的节点，就处于等待通知的状态。等谁的通知呢？不需要其他人，只需要等前一个Znode 的通知就可以了。当前一个Znode 删除的时候，就是轮到了自己占有锁的时候。第一个通知第二个、第二个通知第三个，击鼓传花似的依次向后。

Zookeeper的节点监听机制，可以说能够非常完美的，实现这种击鼓传花似的信息传递。具体的方法是，每一个等通知的Znode节点，只需要监听linsten或者 watch 监视排号在自己前面那个，而且紧挨在自己前面的那个节点。只要上一个节点被删除了，就进行再一次判断，看看自己是不是序号最小的那个节点，如果是，则获得锁。

为什么说Zookeeper的节点监听机制，可以说是非常完美呢？

一条龙式的首尾相接，后面监视前面，就不怕中间截断吗？比如，在分布式环境下，由于网络的原因，或者服务器挂了或者其他的原因，如果前面的那个节点没能被程序删除成功，后面的节点不就永远等待么？

其实，Zookeeper的内部机制，能保证后面的节点能够正常的监听到删除和获得锁。在创建取号节点的时候，尽量创建临时znode 节点而不是永久znode 节点，一旦这个 znode 的客户端与Zookeeper集群服务器失去联系，这个临时 znode 也将自动删除。排在它后面的那个节点，也能收到删除事件，从而获得锁。

说Zookeeper的节点监听机制，是非常完美的。还有一个原因。

Zookeeper这种首尾相接，后面监听前面的方式，可以避免羊群效应。所谓羊群效应就是每个节点挂掉，所有节点都去监听，然后做出反映，这样会给服务器带来巨大压力，所以有了临时顺序节点，当一个节点挂掉，只有它后面的那一个节点才做出反映。

6.2 zookeeper实现分布式锁的示例

zookeeper是通过临时节点来实现分布式锁

import org.apache.curator.RetryPolicy;import org.apache.curator.framework.CuratorFramework;import org.apache.curator.framework.CuratorFrameworkFactory;import org.apache.curator.framework.recipes.locks.InterProcessMutex;import org.apache.curator.retry.ExponentialBackoffRetry;import org.junit.Before;import org.junit.Test;/** * @ClassName ZookeeperLock * @Description TODO * @Author lingxiangxiang * @Date 2:57 PM * @Version 1.0 /public class ZookeeperLock { // 定义共享资源 private static int NUMBER = 10; private static void printNumber() { // 业务逻辑: 秒杀 System.out.println("业务方法开始*\n"); System.out.println("当前的值: " + NUMBER); NUMBER–; try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(“业务方法结束***\n”); } // 这里使用@Test会报错 public static void main(String[] args) { // 定义重试的侧策略 1000 等待的时间(毫秒) 10 重试的次数 RetryPolicy policy = new ExponentialBackoffRetry(1000, 10); // 定义zookeeper的客户端 CuratorFramework client = CuratorFrameworkFactory.builder() .connectString(“10.231.128.95:2181,10.231.128.96:2181,10.231.128.97:2181”) .retryPolicy(policy) .build(); // 启动客户端 client.start(); // 在zookeeper中定义一把锁 final InterProcessMutex lock = new InterProcessMutex(client, “/mylock”); //启动是个线程 for (int i = 0; i <10; i++) { new Thread(new Runnable() { @Override public void run() { try { // 请求得到的锁 lock.acquire(); printNumber(); } catch (Exception e) { e.printStackTrace(); } finally { // 释放锁, 还锁 try { lock.release(); } catch (Exception e) { e.printStackTrace(); } } } }).start(); } }}

7. 基于数据的分布式锁

我们在讨论使用分布式锁的时候往往首先排除掉基于数据库的方案，本能的会觉得这个方案不够“高级”。从性能的角度考虑，基于数据库的方案性能确实不够优异，整体性能对比：缓存 > Zookeeper、etcd > 数据库。也有人提出基于数据库的方案问题很多，不太可靠。数据库的方案可能并不适合于频繁写入的操作.

下面我们来了解一下基于数据库（MySQL）的方案，一般分为3类：基于表记录、乐观锁和悲观锁。

7.1 基于表记录

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们想要获得锁的时候，就可以在该表中增加一条记录，想要释放锁的时候就删除这条记录。

为了更好的演示，我们先创建一张数据库表，参考如下：

CREATE TABLE database_lock ( id BIGINT NOT NULL AUTO_INCREMENT, resource int NOT NULL COMMENT ‘锁定的资源’, description varchar(1024) NOT NULL DEFAULT “” COMMENT ‘描述’, PRIMARY KEY (id), UNIQUE KEY uiq_idx_resource (resource) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=‘数据库分布式锁表’;

获得锁

我们可以插入一条数据：

INSERT INTO database_lock(resource, description) VALUES (1, ‘lock’);

因为表database_lock中resource是唯一索引, 所以其他请求提交到数据库, 就会报错, 并不会插入成功, 只有一个可以插入. 插入成功, 我们就获取到锁

删除锁

INSERT INTO database_lock(resource, description) VALUES (1, ‘lock’);

这种实现方式非常的简单，但是需要注意以下几点：

这种锁没有失效时间，一旦释放锁的操作失败就会导致锁记录一直在数据库中，其它线程无法获得锁。这个缺陷也很好解决，比如可以做一个定时任务去定时清理。这种锁的可靠性依赖于数据库。建议设置备库，避免单点，进一步提高可靠性。这种锁是非阻塞的，因为插入数据失败之后会直接报错，想要获得锁就需要再次操作。如果需要阻塞式的，可以弄个for循环、while循环之类的，直至INSERT成功再返回。这种锁也是非可重入的，因为同一个线程在没有释放锁之前无法再次获得锁，因为数据库中已经存在同一份记录了。想要实现可重入锁，可以在数据库中添加一些字段，比如获得锁的主机信息、线程信息等，那么在再次获得锁的时候可以先查询数据，如果当前的主机信息和线程信息等能被查到的话，可以直接把锁分配给它。