深度优先

https://www.cnblogs.com/javazhiyin/p/15682813.html

存在即是合理的，业务复杂，人员协同性要求高的场景下，这些规范性的东西不按着来虽然不会出错，程序照样跑，但是遵守规范会让程序更具扩展性和可读性，都是前辈血淋淋的宝贵经验，为什么不用？

随着现在后端编程标准化程度越来越高，各种编程模型层出不穷。作为Java开发人员，大部分人不免要接触VO，BO，PO，DO，DTO之类的，但很多同学对这些概念一直以来都是云里雾里，团队开发过程中也总是处于混乱的状态，抓起来就用，本来是规范性的东西，却反而导致更加混乱了。

今天我们把这些概念掰开揉碎来讲解一下，力求有一个清晰的理解，在开发中能有所助益。文中又理解不到位的，也欢迎大家斧正。

概念

• VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

• DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，更符合泛指用于展示层与服务层之间的数据传输对象。

• BO（Business Object）：业务对象，把业务逻辑封装为一个对象，这个对象可以包括一个或多个其它的对象。

• PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

• DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

如果光看这些概念，可能大部分人都理解，但还是很绕，具体用的时候还是不能很好区分，我们来横向做个比较，理解会加深一些。

易混点一：VO和DTO

首先VO是最常用的，但对于这个概念，网上也是众说纷纭，value object 或 view object，一般说视图对象或者值对象，我更倾向理解为视图对象。说白了它就是展示用的，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，我们就把它封装为VO。

VO比较容易混淆的是DTO，DTO是展示层与服务层之间传递数据的对象，可以这样说，对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，那么既然有了VO，为什么还需要DTO呢？

我们举例来说明一下：

某公司有一个后台服务，服务层有一个getUser的方法返回一个系统用户，包含sex(性别)、年龄。对于服务层来说，DTO只从语义上定义，可能是这样的：

1
2
3
4

{
 "gender":"男",
 "age":35
}

但这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，比如管理端要求显示准确的年龄，而应用端为了保护客户隐私，只需要显示一个年龄段即可。

管理端VO：

1
2
3
4

{
 "gender":"男",
 "age":35
}

应用端VO：

1
2
3
4

{
 "gender":"男",
 "age":30~40
}

从这个例子可以看出，DTO很有存在的必要，根据职责单一原则，服务层只负责业务，与具体的表现形式无关，DTO不应该出现与表现形式的耦合，DTO定义的是原始数据，VO再对DTO数据进行解释。这下VO和DTO用法就清晰很多了。

易混点二：BO和PO

PO是持久对象，这个很好理解，就是实体和数据库字段的对应，一个PO的数据结构对应着库中表的结构，表中的一条记录就是一个PO属性，大多数情况下，PO仅仅作为PO只是用来增删改使用。

PO比较容易混淆的是BO，BO是业务对象，对应的是某个具体的业务块，可以包含多个属性、对象。简单点来说，我们可以把BO看作是PO的组合。

我们举例来说明一下：

PO-1是交易记录对象，PO-2是登录记录对象，PO-3是商品浏览记录对象，PO-4是添加购物车记录对象，PO-5是搜索记录对象，BO是个人网站行为对象，BO对象：{PO-1;PO-2;PO-3;PO-4;PO-5}。这样做的优点不言而喻，维护代码的时候查看BO，就能知道这块逻辑涉及多少表（PO）。

易混点三：BO和DTO

搞清楚了BO和PO各自的用途后，我们会发现BO和DTO有重叠功能，一样可以对PO进行排列组合，那BO的存在的意义是什么呢？

从用途上进行根本的区别，BO是业务对象，DTO是数据传输对象，虽然BO也可以排列组合数据，但它的功能是对内的，比如上个例子中的BO对象包括{PO-1;PO-2;PO-3;PO-4;PO-5}还有其他字段属性，但在提供对外接口时，BO对象中的某些属性对象可能用不到或者不方便对外暴露，那么此时DTO只需要在BO的基础上，抽取自己需要的数据，然后对外提供。

在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成。

DO

DO是领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。事实上，DO和PO在绝大部分情况下是一一对应的。阿里巴巴的开发手册中的定义DO等同于PO，即与数据库表结构一一对应，通过DAO层向上传输数据源对象。

上一张图，更加直观的展示这些名词使用的节点：

总结

VO，BO，PO，DTO这样分层还是很有意义的。尤其在团队成员较多的情况下，结构更加一目了然，同时也能很大程度避免多端系统数据所需不一致时，有人修改属性影响其他页面。但也完全没有必要教条主义，把这些全部用上，需要根据所开发的业务复杂度来取舍，如果本身业务逻辑不负责，照搬全上反而让开发变的更复杂。

例如业务不复杂，根本没有多端展示的差异化，VO可以直接拿掉，直接使用DTO传输到前端数据即可。

同时在使用过程中，最重要的是要在团队中达成共识，概念一致，如果使用了这些，但各按各的理解来，甚至抓起来就直接用，反而会让代码变得更乱，还不如直接POJO、DTO打天下。

另附这些概念命名规范：

• 数据对象：xxxPO，xxx即为数据表名。(也可DO)
• 数据传输对象：xxxDTO，xxx为业务领域相关的名称。
• 展示对象：xxxVO，xxx一般为网页名称。
• 业务对象：xxxBO，xxx是业务名称。

转自：https://blog.oldzeng.com/archives/windowsterminalconfig

WindowsTerminal 更新到0.7了， 支持分屏和移动标签， 真香。 但是现在其配置文件和基本设置还不是特别好上手， 有点类似早期的VS Code ，所以这里记录一下常规的设置， 以便使用。

更新日期: 2020-12-26, 目前版本: 1.3

安装

推荐直接从Windows应用商店下载

• 快捷键：
  • Alt Shift + : 竖向分屏
  • Alt Shift - : 横向分屏
  • Alt Shift 方向键 : 调整分屏大小
  • Alt 方向键 : 切换当前分屏

基本配置

如果在之前已经安装过了的话， 升级之后， 配置文件还是老版本的配置文件的样子，这样导致一个问题就是会有一个额外的标题栏， 于是打开就会出现有两个标题栏的丑东西。 解决的办法也比较简单， 把配置文件换成新的配置文件的样子就可以了：

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

// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation
{
    "$schema": "https://aka.ms/terminal-profiles-schema",
 
    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
 
    "profiles":
    [
        {
            // Make changes here to the powershell.exe profile
            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "name": "PowerShell",
            "commandline": "powershell.exe",
            "hidden": false,
            "useAcrylic": true,
            "cursorShape": "filledBox",
            "scrollbarState": "hidden"
        },
        {
            // Make changes here to the cmd.exe profile
            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "name": "cmd",
            "commandline": "CMD",
            "hidden": false
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": false,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure"
        }
    ],
 
    // Add custom color schemes to this array
    "schemes": [],
 
    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": []
}

到这一步， 东西“又不是不能用”了， 下面做一些锦上添花的东西

优化配置

1. 添加到右键菜单

这么个刚需的东西现在竟然需要手动配置， 有点不太友好。 实现的原理也很简单， 就是在注册表中写入一条右键菜单配置， 为了美观一点，我么给它加上一个图标：

1. 下载图标文件, 将图标文件保存到某个目录中，可以在Local目录下新建个子目录， 如： C:\Users\[用户名]\AppData\Local\terminal 喜欢原理cmd图标的也可以用这个： https://raw.githubusercontent.com/microsoft/terminal/master/res/console.ico

2. 配置注册表 将下面代码保存成aa.reg文件, 命名随意， 路径替换， 双击运行。

   1 2 3 4 5 6 7 8

   Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Directory\Background\shell\wt] @="Terminal here" "Icon"="C:\\Users\\[用户名]\\AppData\\Local\\terminal\\terminal.ico" [HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command] @="C:\\Users\\[用户名]\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe"

3. 修改配置 上面一步， 成功实现添加右键菜单， 但是打开之后都是默认路径。 所以需要手动改一下路径。 配置文件的每一个profile配置下都加上这么一行：

   1	"startingDirectory": "./"

2. 自定义主题

原生主题FFF字色有点晃眼， 此时自己可以定义一套Schema来自定义主题， 我现在用的这份主题配置不是原创， 网上抄的， 但是找不到源码了。 具体的做法就是在Schema数组中添加一个对象， 配置好对应的颜色， 然还在想要使用主题的 Profile 对象中指定 colorScheme 就可以了。 最后的配置放在最后

3. 设置背景透明和配置图片

这两个属性设置也是在Profile 中设置， 现在的设置也很简单

1
2
3
4
5

"useAcrylic": true,        // 打开透明效果
"acrylicOpacity": 0.8,     // 背景透明度

"backgroundImage": "E:\\Images\\wallpaper\\1.jpg", // 背景图片效果
"backgroundImageOpacity": 0.3,                        // 背景图片透明度

4. 设置SSH连接快捷方式

设置SSH远程连接也是一样, 通过添加一个Profile就可以完成. 具体做法是， 添加一个新的Profile， 设置基本属性后， 添加一条 commonLine 的属性， 如：

code

1

"commonLine": "ssh someone@123.231.132.123`

为了省去输入密码的步骤， 可以将ssh公钥上传至对应的服务器中， 比如对应上面这条配置， 具体做法如下：

1. 找到123.231.132.123机器上面/home/someone/.ssh/authorized_keys 文件， 如果没有， 则依次创建
2. 复制本机公钥的内容（C:\Users\[用户名].ssh\id_rsa.pub) 到上面创建的文件中。

集成 GitBash

如果电脑安装了 Git, 可以将 GitBash 集成到 Terminal 中, 体验效果炫酷且无缝切换的客户端. 具体的方法就是配置一个新的Profile , 需要注意的是, 执行文件的路径, 不是 Git 安装目录下的 git-bash.exe , 而是 bin/bash.exe , 然后再找个合适的图标就好了, 参考图标:

code

1
2
3
4
5
6

{
    "guid": "{714caed7-ef94-468e-b73c-797c4b064fa6}",
    "name": "Git",
    "icon": "C:\\Program Files\\Git\\git.png",
    "commandline": "C:\\Program Files\\Git\\bin\\bash.exe"
}

集成 WSL

如果 Windows 安装了 WSL, 会自动配置一个对应操作系统的 Profile, 如果没有的话, 也可以自己配置, 大概内容如下:

code

1
2
3
4
5

{
    "guid": "{98580abb-df41-5a69-97cc-d558b1e5c68a}",
    "name": "centos8",
    "source": "Windows.Terminal.Wsl"
}

搞定。

最终效果：

附上配置文件：

code

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

// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation
{
    "$schema": "https://aka.ms/terminal-profiles-schema",
 
    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
 
    "profiles":
    [
        {
            // Make changes here to the powershell.exe profile
            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "name": "PowerShell",
            "commandline": "powershell.exe",
            "hidden": false,
            "startingDirectory": "./",
            "fontFace": "Cascadia Code",
            "acrylicOpacity": 0.8,
            "useAcrylic": true,
            "colorScheme": "Firewatch",
            "cursorColor": "#FFFFFF",
            "cursorShape": "filledBox",
            "fontSize": 12,
            "padding": "8, 8, 8, 8",
            "backgroundImage": "E:\\Images\\wallpaper\\1.jpg",
            "backgroundImageOpacity": 0.3,
            "scrollbarState": "hidden"
        },
        {
            // Make changes here to the cmd.exe profile
            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "name": "cmd",
            "commandline": "CMD",
            "hidden": false,
            "startingDirectory": "./",
            "fontFace": "Cascadia Code"
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": false,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure",
            "startingDirectory": "./",
            "fontFace": "Cascadia Code"
        }
    ],
 
    // Add custom color schemes to this array
    "schemes": [
        {
            "name": "Firewatch",
            "black": "#585f6d",
            "red": "#d95360",
            "green": "#5ab977",
            "yellow": "#dfb563",
            "blue": "#4d89c4",
            "purple": "#d55119",
            "cyan": "#44a8b6",
            "white": "#e6e5ff",
            "brightBlack": "#585f6d",
            "brightRed": "#d95360",
            "brightGreen": "#5ab977",
            "brightYellow": "#dfb563",
            "brightBlue": "#4c89c5",
            "brightPurple": "#d55119",
            "brightCyan": "#44a8b6",
            "brightWhite": "#e6e5ff",
            "background": "#1e2027",
            "foreground": "#f3f3f3"
        }
    ],
 
    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": [] 
}

转自：https://juejin.cn/post/6844903830442737671

前言

本篇文章主要介绍基于Redis的分布式锁实现到底是怎么一回事，其中参考了许多大佬写的文章，算是对分布式锁做一个总结

分布式锁概览

在多线程的环境下，为了保证一个代码块在同一时间只能由一个线程访问，Java中我们一般可以使用synchronized语法和ReetrantLock去保证，这实际上是本地锁的方式。但是现在公司都是流行分布式架构，在分布式环境下，如何保证不同节点的线程同步执行呢？

实际上，对于分布式场景，我们可以使用分布式锁，它是控制分布式系统之间互斥访问共享资源的一种方式。

比如说在一个分布式系统中，多台机器上部署了多个服务，当客户端一个用户发起一个数据插入请求时，如果没有分布式锁机制保证，那么那多台机器上的多个服务可能进行并发插入操作，导致数据重复插入，对于某些不允许有多余数据的业务来说，这就会造成问题。而分布式锁机制就是为了解决类似这类问题，保证多个服务之间互斥的访问共享资源，如果一个服务抢占了分布式锁，其他服务没获取到锁，就不进行后续操作。大致意思如下图所示（不一定准确）：

分布式锁的特点

分布式锁一般有如下的特点：

• 互斥性： 同一时刻只能有一个线程持有锁
• 可重入性： 同一节点上的同一个线程如果获取了锁之后能够再次获取锁
• 锁超时：和J.U.C中的锁一样支持锁超时，防止死锁
• 高性能和高可用： 加锁和解锁需要高效，同时也需要保证高可用，防止分布式锁失效
• 具备阻塞和非阻塞性：能够及时从阻塞状态中被唤醒

分布式锁的实现方式

我们一般实现分布式锁有以下几种方式：

• 基于数据库
• 基于Redis
• 基于zookeeper

本篇文章主要介绍基于Redis如何实现分布式锁

Redis的分布式锁实现

1. 利用setnx+expire命令 (错误的做法)

Redis的SETNX命令，setnx key value，将key设置为value，当键不存在时，才能成功，若键存在，什么也不做，成功返回1，失败返回0 。 SETNX实际上就是SET IF NOT Exists的缩写

因为分布式锁还需要超时机制，所以我们利用expire命令来设置，所以利用setnx+expire命令的核心代码如下：

1
2
3
4
5
6
7
8
9
10

public boolean tryLock(String key,String requset,int timeout) {
    Long result = jedis.setnx(key, requset);
    // result = 1时，设置成功，否则设置失败
    if (result == 1L) {
        return jedis.expire(key, timeout) == 1L;
    } else {
        return false;
    }
}
复制代码

实际上上面的步骤是有问题的，setnx和expire是分开的两步操作，不具有原子性，如果执行完第一条指令应用异常或者重启了，锁将无法过期。

一种改善方案就是使用Lua脚本来保证原子性（包含setnx和expire两条指令）

2. 使用Lua脚本（包含setnx和expire两条指令）

代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13

public boolean tryLock_with_lua(String key, String UniqueId, int seconds) {
    String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            "redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";
    List<String> keys = new ArrayList<>();
    List<String> values = new ArrayList<>();
    keys.add(key);
    values.add(UniqueId);
    values.add(String.valueOf(seconds));
    Object result = jedis.eval(lua_scripts, keys, values);
    //判断是否成功
    return result.equals(1L);
}
复制代码

3. 使用 set key value [EX seconds][PX milliseconds][NX|XX] 命令 (正确做法)

Redis在 2.6.12 版本开始，为 SET 命令增加一系列选项：

1
2

SET key value[EX seconds][PX milliseconds][NX|XX]
复制代码

• EX seconds: 设定过期时间，单位为秒
• PX milliseconds: 设定过期时间，单位为毫秒
• NX: 仅当key不存在时设置值
• XX: 仅当key存在时设置值

set命令的nx选项，就等同于setnx命令，代码过程如下：

1
2
3
4

public boolean tryLock_with_set(String key, String UniqueId, int seconds) {
    return "OK".equals(jedis.set(key, UniqueId, "NX", "EX", seconds));
}
复制代码

value必须要具有唯一性，我们可以用UUID来做，设置随机字符串保证唯一性，至于为什么要保证唯一性？假如value不是随机字符串，而是一个固定值，那么就可能存在下面的问题：

• 1.客户端1获取锁成功
• 2.客户端1在某个操作上阻塞了太长时间
• 3.设置的key过期了，锁自动释放了
• 4.客户端2获取到了对应同一个资源的锁
• 5.客户端1从阻塞中恢复过来，因为value值一样，所以执行释放锁操作时就会释放掉客户端2持有的锁，这样就会造成问题

所以通常来说，在释放锁时，我们需要对value进行验证

释放锁的实现

释放锁时需要验证value值，也就是说我们在获取锁的时候需要设置一个value，不能直接用del key这种粗暴的方式，因为直接del key任何客户端都可以进行解锁了，所以解锁时，我们需要判断锁是否是自己的，基于value值来判断，代码如下：

1
2
3
4
5
6

public boolean releaseLock_with_lua(String key,String value) {
    String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then " +
            "return redis.call('del',KEYS[1]) else return 0 end";
    return jedis.eval(luaScript, Collections.singletonList(key), Collections.singletonList(value)).equals(1L);
}
复制代码

这里使用Lua脚本的方式，尽量保证原子性。

使用 set key value [EX seconds][PX milliseconds][NX|XX] 命令 看上去很OK，实际上在Redis集群的时候也会出现问题，比如说A客户端在Redis的master节点上拿到了锁，但是这个加锁的key还没有同步到slave节点，master故障，发生故障转移，一个slave节点升级为master节点，B客户端也可以获取同个key的锁，但客户端A也已经拿到锁了，这就导致多个客户端都拿到锁。

所以针对Redis集群这种情况，还有其他方案

4. Redlock算法 与 Redisson 实现

Redis作者 antirez基于分布式环境下提出了一种更高级的分布式锁的实现Redlock，原理如下：

下面参考文章Redlock：Redis分布式锁最牛逼的实现 和 redis.io/topics/dist…

假设有5个独立的Redis节点（注意这里的节点可以是5个Redis单master实例，也可以是5个Redis Cluster集群，但并不是有5个主节点的cluster集群）：

• 获取当前Unix时间，以毫秒为单位
• 依次尝试从5个实例，使用相同的key和具有唯一性的value(例如UUID)获取锁，当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应用小于锁的失效时间，例如你的锁自动失效时间为10s，则超时时间应该在5~50毫秒之间，这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁
• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间，当且仅当从大多数(N/2+1，这里是3个节点)的Redis节点都取到锁，并且使用的时间小于锁失败时间时，锁才算获取成功。
• 如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）
• 如果某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）

Redisson实现简单分布式锁

对于Java用户而言，我们经常使用Jedis，Jedis是Redis的Java客户端，除了Jedis之外，Redisson也是Java的客户端，Jedis是阻塞式I/O，而Redisson底层使用Netty可以实现非阻塞I/O，该客户端封装了锁的，继承了J.U.C的Lock接口，所以我们可以像使用ReentrantLock一样使用Redisson，具体使用过程如下。

1. 首先加入POM依赖

1
2
3
4
5
6

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.10.6</version>
</dependency>
复制代码

2. 使用Redisson，代码如下(与使用ReentrantLock类似）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// 1. 配置文件
Config config = new Config();
config.useSingleServer()
        .setAddress("redis://127.0.0.1:6379")
        .setPassword(RedisConfig.PASSWORD)
        .setDatabase(0);
//2. 构造RedissonClient
RedissonClient redissonClient = Redisson.create(config);

//3. 设置锁定资源名称
RLock lock = redissonClient.getLock("redlock");
lock.lock();
try {
    System.out.println("获取锁成功，实现业务逻辑");
    Thread.sleep(10000);
} catch (InterruptedException e) {
    e.printStackTrace();
} finally {
    lock.unlock();
}
复制代码

关于Redlock算法的实现，在Redisson中我们可以使用RedissonRedLock来完成，具体使用细节可以参考大佬的文章： mp.weixin.qq.com/s/8uhYult2h…

Redis实现的分布式锁轮子

下面利用SpringBoot + Jedis + AOP的组合来实现一个简易的分布式锁。

1. 自定义注解

自定义一个注解，被注解的方法会执行获取分布式锁的逻辑

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

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface RedisLock {
    /**
     * 业务键
     *
     * @return
     */
    String key();
    /**
     * 锁的过期秒数,默认是5秒
     *
     * @return
     */
    int expire() default 5;

    /**
     * 尝试加锁，最多等待时间
     *
     * @return
     */
    long waitTime() default Long.MIN_VALUE;
    /**
     * 锁的超时时间单位
     *
     * @return
     */
    TimeUnit timeUnit() default TimeUnit.SECONDS;
}
复制代码

2. AOP拦截器实现

在AOP中我们去执行获取分布式锁和释放分布式锁的逻辑，代码如下：

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

@Aspect
@Component
public class LockMethodAspect {
    @Autowired
    private RedisLockHelper redisLockHelper;
    @Autowired
    private JedisUtil jedisUtil;
    private Logger logger = LoggerFactory.getLogger(LockMethodAspect.class);

    @Around("@annotation(com.redis.lock.annotation.RedisLock)")
    public Object around(ProceedingJoinPoint joinPoint) {
        Jedis jedis = jedisUtil.getJedis();
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();

        RedisLock redisLock = method.getAnnotation(RedisLock.class);
        String value = UUID.randomUUID().toString();
        String key = redisLock.key();
        try {
            final boolean islock = redisLockHelper.lock(jedis,key, value, redisLock.expire(), redisLock.timeUnit());
            logger.info("isLock : {}",islock);
            if (!islock) {
                logger.error("获取锁失败");
                throw new RuntimeException("获取锁失败");
            }
            try {
                return joinPoint.proceed();
            } catch (Throwable throwable) {
                throw new RuntimeException("系统异常");
            }
        }  finally {
            logger.info("释放锁");
            redisLockHelper.unlock(jedis,key, value);
            jedis.close();
        }
    }
}

复制代码

3. Redis实现分布式锁核心类

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
101
102
103
104
105

@Component
public class RedisLockHelper {
    private long sleepTime = 100;
    /**
     * 直接使用setnx + expire方式获取分布式锁
     * 非原子性
     *
     * @param key
     * @param value
     * @param timeout
     * @return
     */
    public boolean lock_setnx(Jedis jedis,String key, String value, int timeout) {
        Long result = jedis.setnx(key, value);
        // result = 1时，设置成功，否则设置失败
        if (result == 1L) {
            return jedis.expire(key, timeout) == 1L;
        } else {
            return false;
        }
    }

    /**
     * 使用Lua脚本，脚本中使用setnex+expire命令进行加锁操作
     *
     * @param jedis
     * @param key
     * @param UniqueId
     * @param seconds
     * @return
     */
    public boolean Lock_with_lua(Jedis jedis,String key, String UniqueId, int seconds) {
        String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
                "redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";
        List<String> keys = new ArrayList<>();
        List<String> values = new ArrayList<>();
        keys.add(key);
        values.add(UniqueId);
        values.add(String.valueOf(seconds));
        Object result = jedis.eval(lua_scripts, keys, values);
        //判断是否成功
        return result.equals(1L);
    }

    /**
     * 在Redis的2.6.12及以后中,使用 set key value [NX] [EX] 命令
     *
     * @param key
     * @param value
     * @param timeout
     * @return
     */
    public boolean lock(Jedis jedis,String key, String value, int timeout, TimeUnit timeUnit) {
        long seconds = timeUnit.toSeconds(timeout);
        return "OK".equals(jedis.set(key, value, "NX", "EX", seconds));
    }

    /**
     * 自定义获取锁的超时时间
     *
     * @param jedis
     * @param key
     * @param value
     * @param timeout
     * @param waitTime
     * @param timeUnit
     * @return
     * @throws InterruptedException
     */
    public boolean lock_with_waitTime(Jedis jedis,String key, String value, int timeout, long waitTime,TimeUnit timeUnit) throws InterruptedException {
        long seconds = timeUnit.toSeconds(timeout);
        while (waitTime >= 0) {
            String result = jedis.set(key, value, "nx", "ex", seconds);
            if ("OK".equals(result)) {
                return true;
            }
            waitTime -= sleepTime;
            Thread.sleep(sleepTime);
        }
        return false;
    }
    /**
     * 错误的解锁方法—直接删除key
     *
     * @param key
     */
    public void unlock_with_del(Jedis jedis,String key) {
        jedis.del(key);
    }

    /**
     * 使用Lua脚本进行解锁操纵，解锁的时候验证value值
     *
     * @param jedis
     * @param key
     * @param value
     * @return
     */
    public boolean unlock(Jedis jedis,String key,String value) {
        String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then " +
                "return redis.call('del',KEYS[1]) else return 0 end";
        return jedis.eval(luaScript, Collections.singletonList(key), Collections.singletonList(value)).equals(1L);
    }
}
复制代码

4. Controller层控制

定义一个TestController来测试我们实现的分布式锁

1
2
3
4
5
6
7
8
9

@RestController
public class TestController {
    @RedisLock(key = "redis_lock")
    @GetMapping("/index")
    public String index() {
        return "index";
    }
}
复制代码

小结

分布式锁重点在于互斥性，在任意一个时刻，只有一个客户端获取了锁。在实际的生产环境中，分布式锁的实现可能会更复杂，而我这里的讲述主要针对的是单机环境下的基于Redis的分布式锁实现，至于Redis集群环境并没有过多涉及，有兴趣的朋友可以查阅相关资料。