分布式锁简介

当我们有多个进程或者线程需要共享资源时，都不可避免的使用锁来防止资源被篡改。这就是编程中非常重要的概念--锁。

编程中有两种方式，一种是乐观锁，一种是悲观锁。就像心理学中的描述一样，乐观和悲观并没有谁好谁坏。同样乐观锁和悲观锁也只是适用的场景不一样，并没有说谁一定好，谁一定坏。

乐观锁：总是假设最好的情况，即自己取资源时认为别人不会修改。然后在更新的时候判断一下别人有没有更新这个资源。
悲观锁：总是假设最坏的情况，每次去资源时都认为别人会修改。所以每次取资源时都要给资源上锁。

乐观锁其实并没有使用锁，因为乐观锁在操作时总是乐观的认为不会有资源争抢问题，所以也不会上锁。相比于悲观锁来说，乐观锁减少了加锁和解锁的步骤，也不会在操作时阻塞，一直占用着资源。比较适合“读”比较多的场景。乐观锁的实现方式常见的有两种：版本号和 CAS （Compare and Swap）：

版本号：在资源表加上一个版本号，表示资源被修改的次数。这样当需要更新时可以通过检查版本号来判定是否被别人更新。
CAS算法：全称是 Compare and Swap，是一种无锁算法。其具有三个操作数：内存地址V，旧的预期值A，新的预期值B。当V中的值和A相同时，则用新值B替换V中的值，否则不执行更新。CAS的比较和替换是一个原子操作，所以能够保证并发安全。

ABA问题：资源的值一样并不代表资源没有被修改过，比如一个值开始读到的值是A，然后被进程a修改一段时间，这段时间被另一个进程b修改成B，然后又修改成A。a修改完成后再去读，发现值还是A，就认为值没有被修改过。但其实值已经被修改过了。所以即使操作最后成功了，但是并不能保证整个过程是没有问题的。

分布式系统中CAP原则大家并不陌生，一致性（Consistency）、可用性（Availability）、容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

大多数场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。

针对分布式锁的实现，目前比较常用的有以下几种方案：

• 基于数据库实现分布式锁
• 基于缓存（redis，memcached，tair）实现分布式锁
• 基于Zookeeper实现分布式锁

基于数据库实现分布式锁

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。

当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

redis 分布式锁

• 互斥（只能有一个客户端获取锁）
• 不能死锁
• 容错（只要大部分 redis 节点创建了这把锁就可以）

普通的分布式锁

第一个最普通的实现方式，就是在 redis 里使用 setnx 命令创建一个 key，这样就算加锁。

SET resource_name my_random_value NX PX 30000

执行这个命令就 ok。

• NX：表示只有 key 不存在的时候才会设置成功。（如果此时 redis 中存在这个 key，那么设置失败，返回 nil）
• PX 30000：意思是 30s 后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了。

释放锁就是删除 key ，但是一般可以用 lua 脚本删除，判断 value 一样才删除：

-- 删除锁的时候，找到 key 对应的 value，跟自己传过去的 value 做比较，如果是一样的才删除。
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

RedLock 算法

1. 获取当前时间戳，单位是毫秒；
2. 跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
3. 尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1；
4. 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
5. 要是锁建立失败了，那么就依次之前建立过的锁删除；
6. 只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。

zookeeper使用场景如下：

• 分布式协调

• 分布式锁

• 元数据/配置信息管理

• HA高可用性

zk分布式锁

zk 分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时 znode，此时创建成功了就获取了这个锁；这个时候别的客户端来创建锁会失败，只能注册个监听器监听这个锁。释放锁就是删除这个 znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以再次重新加锁。

另一种方式，创建临时顺序节点：如果有一把锁，被多个人给竞争，此时多个人会排队，第一个拿到锁的人会执行，然后释放锁；后面的每个人都会去监听排在自己前面的那个人创建的 node 上，一旦某个人释放了锁，排在自己后面的人就会被 zookeeper 给通知，一旦被通知了之后，就 ok 了，自己就获取到了锁，就可以执行代码了。

对比

• redis 分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。
• zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。

如果是 redis 获取锁的那个客户端 出现 bug 挂了，那么只能等待超时时间之后才能释放锁；而 zk 的话，因为创建的是临时 znode，只要客户端挂了，znode 就没了，此时就自动释放锁。

zk 的分布式锁比 redis 的分布式锁牢靠、而且模型简单易用。

关注公众号，发送 ms 免费获取 海量JAVA大厂面试题。