文章目录
- 导图
- Pre
- 概述
- 概述
- 1. 分布式互斥和临界资源的协调
- 2. 分布式锁的基本原理
- 3. 分布式锁的实现方式
- a. 基于数据库实现的分布式锁
- b. 基于Redis实现的分布式锁
- c. 基于Zookeeper实现的分布式锁
- 4. 高并发场景下的分布式锁优化
- a. 分段锁（Sharded Locks）
- b. 锁竞争优化
- c. 锁超时和自动解锁
- d. 异步处理
- 5. 分布式锁的高可用性保障
- 分布式锁的由来和定义
- 进程内对临界资源的竞态操作
- 分布式锁示意图
- 通过 Redis 缓存实现分布式锁
- 通过 ZooKeeper 实现分布式锁
- 分布式分段加锁
导图
Pre
分布式协同 - 分布式系统的特性与互斥问题
深入理解分布式技术 - 分布式锁的应用场景和主流方案
深入理解分布式技术 - Redis 分布式锁解决方案
Redis进阶- Redisson分布式锁实现原理及源码解析
Redis进阶-细说分布式锁
Apache ZooKeeper - 使用ZK实现分布式锁(非公平锁/公平锁/共享锁 )
概述
概述
1. 分布式互斥和临界资源的协调
在分布式系统中，由于多个节点（进程）并发执行，可能会访问共享的临界资源。为了保证资源的正确性和一致性，必须保证同一时刻只有一个节点能够访问该资源，这就是分布式互斥的需求。没有这种互斥机制时，多个节点可能会同时修改共享数据，导致数据不一致或不正确。
例如，在高并发的秒杀系统中，多个订单服务节点可能会同时扣减库存，如果没有互斥控制，可能导致库存超卖的问题。
2. 分布式锁的基本原理
分布式锁是一种确保在分布式环境中，多个节点对临界资源进行顺序访问的机制。其基本原理是：每次只有一个节点能够获得锁并访问资源，其他节点需要等待锁释放。锁通常有两种状态：
- 持有锁的节点：该节点正在访问临界资源。
- 等待锁的节点：该节点在等待资源访问权限。
当一个节点获取锁时，其他节点必须等待，直到该节点释放锁才能继续访问资源。
3. 分布式锁的实现方式
分布式锁的实现方式有多种，常见的方式包括：
a. 基于数据库实现的分布式锁
数据库可以通过表记录来实现分布式锁。例如，可以在数据库中创建一个“锁”表，只有获取到该表的某一行记录的节点才能访问资源。为了保证锁的唯一性，通常会使用数据库的事务和悲观锁机制。
优点：
- 实现简单，适用于使用数据库的系统。
缺点：
- 性能较低，锁竞争严重时会影响数据库的读写性能。
b. 基于Redis实现的分布式锁
Redis提供了丰富的锁机制，最常用的是通过SETNX命令（“SET if Not eXists”）来实现分布式锁。SETNX命令可以确保只有一个节点能够成功设置一个键，如果该键已经存在，则表示锁已被其他节点持有。
Redis分布式锁的常见实现包括：
- 使用SETNX命令设置锁。
- 设置超时，确保即使进程崩溃或网络断开，锁也能被释放，避免死锁。
- 使用RedLock算法，确保在多个Redis实例上使用锁，提高系统的可用性和容错性。
优点：
- 性能高，支持高并发。
- 支持分布式环境下的锁管理。
缺点：
- 需要确保锁的超时和重试机制，避免死锁。
c. 基于Zookeeper实现的分布式锁
Zookeeper提供了原生的分布式协调服务，能够很方便地实现分布式锁。通过在Zookeeper中创建临时节点，每个进程尝试创建一个节点作为锁的标识，只有一个进程能够成功创建临时节点并获得锁。
Zookeeper的分布式锁通常涉及以下步骤：
- 创建一个顺序临时节点。
- 通过Zookeeper提供的Watcher机制监控其他节点的创建，保证获取锁的顺序。
- 在完成任务后删除锁节点。
优点：
- 强一致性，适合需要强一致性的分布式系统。
缺点：
- 性能相对较低，适合对一致性要求较高的场景。
4. 高并发场景下的分布式锁优化
在高并发、大流量的场景下（如秒杀系统），多个请求可能会同时竞争资源，造成系统性能瓶颈。为了应对这些挑战，可以通过以下方式优化分布式锁的性能：
a. 分段锁（Sharded Locks）
为了提高并发性能，可以对资源进行分段，使用多个锁来分担压力。例如，将库存分为多个段，每个段使用独立的锁，这样多个请求就可以并行地访问不同段的库存，减少锁竞争。
b. 锁竞争优化
优化锁的获取和释放机制，减少锁竞争的时间。可以通过乐观锁和**CAS（Compare And Swap）**等技术减少锁的争用。
c. 锁超时和自动解锁
为了避免死锁，应该为锁设置超时时间，确保即使持锁进程崩溃，锁也能被及时释放。
d. 异步处理
对于不需要立即执行的任务，可以考虑异步处理，通过消息队列等机制将任务延迟执行，从而减少对锁的依赖。
5. 分布式锁的高可用性保障
在分布式锁的实现过程中，要确保协调者（如Redis、Zookeeper）具有高可用性。在高并发的环境中，单点故障可能会导致锁服务不可用，从而影响系统的稳定性。
为了提高可用性，可以：
- 对Redis使用集群模式，确保高可用性。
- 使用Zookeeper集群，提高容错性。
- 采用RedLock等算法，确保在多个节点上都能获得锁，从而避免单点故障。
分布式锁的由来和定义
通常来讲，在消费者下订单时也会对库存进行扣减，此时订单服务会更新库存变量，其实就是将其值减 1。如果有两个用户同时对同一商品下单，就会造成对同一商品库存进行扣减的情况。我们将库存称作临界资源，扣减库存的动作称为竞态。切换到在进程内，竞态可以理解为两个线程（两个用户请求）争夺临界资源，解决办法是在这个资源上加一把锁。
进程内对临界资源的竞态操作
如下所示，线程 B 先到达，于是让其持有这把锁，并访问临界资源，之后线程 A 到达时由于没有锁，就进入等待队列，等线程 B 访问完毕并释放锁以后，线程 A 持有锁，可以访问临界资源
分布式锁示意图
为了面对高并发的下单请求，对订单服务做了水平扩展，因此订单服务通常是分散部署的。原来是进程内的多线程对临界资源产生的竞态，现在变成了分布式应用系统中的多个服务（进程）对临界资源的竞态对订单服务进行了水平扩展，将其从原来的一个扩展为两个，分别是订单服务 A 和 B，这两个服务可能会同时扣减库存。
由于是不同的服务或者进程，它们不知道对方的存在，因此共同访问的临界资源应该独立于服务，保存在一个公共的存储区域中，让水平扩展的订单服务都可以访问到。另外，可以通过锁机制，保证多服务并发请求时的竞态不会造成超卖情况，这和解决进程内竞态的方式相同。通过给临界资源加上一把锁，可以让并发操作变成串行的方式。这个锁就是分布式锁，其实现方式多种多样，比如通过数据库、Redis 缓存、ZooKeeper 实现
用数据库实现分布式锁比较简单，就是创建一张锁表。要锁住临界资源并对其访问时，在锁表中增加一条记录即可；删除某条记录就可释放相应的临界资源。数据库对临界资源做了唯一性约束，如果有访问临界资源的请求同时提交到数据库，数据库会保证只有一个请求能够得到锁，然后只有得到锁的这个请求才可以访问临界资源。
由于此类操作属于数据库 IO 操作，效率不高，而且频繁操作会增大数据库的开销，因此这种方式在高并发、对性能要求较高的场景中使用得并不多，这里不做详细介绍。
通过 Redis 缓存实现分布式锁
库存作为临界资源会遭遇高并发的请求访问，为了提高效率，可以将库存信息放到缓存中。以流行的 Redis 为例，用其存放库存信息，当多个进程同时请求访问库存时会出现资源争夺现象，也就是分布式程序争夺唯一资源。为了解决这个问题，需要实现分布式锁
假设有多个扣减服务用于响应用户的下单请求，这些服务接收到请求后会去访问 Redis 缓存中存放的库存信息，每接收一次用户请求，就将 Redis 中存放的库存量减去 1。
一个进程持有锁后，就可以访问 Redis 中的库存资源，且在其访问期间其他进程是不能访问的。如果该进程长期没有释放锁，就会造成其他进程饥饿，因此需要考虑锁的过期时间，设置超时时间。
通过 ZooKeeper 实现分布式锁
使用 Redis 缓存实现分布式锁，使同时访问临界资源的进程由并行执行变为串行执行。按照同样的思路，ZooKeeper 中的 DataNode 也可以保证两个进程的访问顺序是串行的，两个库存扣减进程会在 ZooKeeper 上建立顺序的 DataNode，DataNode 的顺序就是进程访问临界资源的顺序，这样避免了多个进程同时访问临界资源，起到了锁的作用。
在 ZooKeeper 中建立一个 Locker 的 DataNode 节点，在此节点下面建立子 DataNode 来保证先后顺序。即便是两个进程同时申请新建节点，也会按照先后顺序建立两个节点
整个过程具体如下。
- (1) 当库存服务 A 想要访问库存时，需要先申请锁，于是在 ZooKeeper 的 Locker 节点下面新建一个 DataNode1 节点，表明可以扣减库存。
- (2) 库存服务 B 在服务 A 后面申请库存的访问权限，由于申请锁操作排在服务 A 后面，因此节点会按照次序建立在 DataNode1 下面，为 DataNode2。
- (3) 库存服务 A 在申请锁成功以后访问库存资源，并完成扣减。这段时间内库存服务 B 一直等待，直到库存服务 A 扣减完毕，ZooKeeper 中 Locker 下面的 DataNode1 节点被删除。
- (4) DataNode1 被删除后，DataNode2 作为序号最靠前的节点，对应的库存服务 B 能够访问并扣减库存
可知： ZooKeeper 实现分布式锁的基本原理是按照顺序建立 DataNode 节点
分布式分段加锁
通过 Redis 缓存和 ZooKeeper 实现分布式锁依据的都是把并行执行转换成串行执行的思路。现在假设处理一次下单扣减等逻辑需要 20ms，那么同时有 500 个扣减请求串行执行的话，就需要 20ms×500 =10 000ms，也就是 10 s。如果并发数量再高一点，即使可以将订单服务水平扩展成很多个，使用队列做缓冲，也需要很久才能完成。
实际上，有我们可以将原理中的临界资源——库存由一个分成多个，然后将分得的库存段放到临界资源中，例如库存量为 500，将其分成 50 份，每份放 10 个库存，并从 1 到 50 标号，每个号码中就放 10 个库存。当高并发来临时，订单服务按序或者随机请求 1 到 10 号库存段，如果请求的库存段没有被锁，就获取锁并进行扣减操作；如果请求的库存段被其他请求锁住了，就换一个库存段进行扣减。这样在无形中提高了并发量，可以用在秒杀系统中
扣减库存请求 1 获取了库存段 1 的资源后，扣减库存请求 2 再获取库存段 1 时会发现这部分库存资源已经被锁住了，于是找库存段 2 获取资源，发现这部分库存资源并没有被锁住，于是执行扣减操作。
