分布式锁

分布式锁是指分布式环境下，系统部署在多个机器中，实现多进程分布式互斥的一种锁。为了保证多个进程能看到锁，锁被存在公共存储（比如 Redis、Memcache、数据库等三方存储中），以实现多个进程并发访问同一个临界资源，同一时刻只有一个进程可访问共享资源，确保数据的一致性。

分布式锁的三种实现方法及对比

基于数据库实现分布式锁

这里的数据库指的是关系型数据库

要实现分布式锁，最直接的方式就是创建一张锁表，然后通过操作该表中的数据来实现。当我们要锁住某个资源时，就在该表中增加一条记录，想要释放锁的时候就删除这条记录。数据库对共享资源做了唯一性约束，如果有多个请求被同时提交到数据库的话，数据库会保证只有一个操作可以成功，操作成功的那个线程就获得了访问共享资源的锁，可以进行操作。

基于数据库实现的分布式锁，是最容易理解的。

但是，因为数据库需要落到硬盘上，频繁读取数据库会导致 IO 开销大，因此这种分布式锁适用于并发量低，对性能要求低的场景。对于双 11、双 12 等需求量激增的场景，数据库锁是无法满足其性能要求的。而在平日的购物中，我们可以在局部场景中使用数据库锁实现对资源的互斥访问

基于数据库实现的分布式锁比较简易，绝招在于创建一张锁表，为申请者在锁表里建立一条记录，记录建立成功则获得锁，消除记录则释放锁。

该方法依赖于数据库，

主要有两个缺点：

1.单点故障问题。一旦数据库不可用，会导致整个系统崩溃。

2.死锁问题。数据库锁没有失效时间，未获得锁的进程只能一直等待已获得锁的进程主动释放锁。一旦已获得锁的进程挂掉或者解锁操作失败，会导致锁记录一直存在数据库中，其他进程无法获得锁。

基于缓存实现分布式锁

基于缓存实现分布式锁的方式，非常适合解决这种场景下的问题。所谓基于缓存，也就是说把数据存放在计算机内存中，不需要写入磁盘，减少了 IO 读写

Redis 通常可以使用 setnx(key, value) 函数来实现分布式锁。key 和 value 就是基于缓存的分布式锁的两个属性，其中 key 表示锁 id，value = currentTime + timeOut，表示当前时间 + 超时时间。

也就是说，某个进程获得 key 这把锁后，如果在 value 的时间内未释放锁，系统就会主动释放锁。

setnx 函数的返回值有 0 和 1：返回 1，说明该服务器获得锁，

setnx 将 key 对应的 value 设置为当前时间 + 锁的有效时间。返回 0，说明其他服务器已经获得了锁，进程不能进入临界区。

该服务器可以不断尝试 setnx 操作，以获得锁

用户 A 的请求因为网速快，最先到达 Server2，setnx 操作返回 1，并获取到购买吹风机的锁；

用户 B 和用户 C 的请求，几乎同时到达了 Server1 和 Server3，但因为这时 Server2 获取到了吹风机数据的锁，所以只能加入等待队列。Server2 获取到锁后，负责管理吹风机的服务器执行业务逻辑，只用了 1s 就完成了订单。订单请求完成后，删除锁的 key，从而释放锁。

此时，排在第二顺位的 Server1 获得了锁，可以访问吹风机的数据资源。但不巧的是，Server1 在完成订单后发生了故障，无法主动释放锁。于是，排在第三顺位的 Server3 只能等设定的有效时间（比如 30 分钟）到期，锁自动释放后，才能访问吹风机的数据资源，也就是说用户 C 只能到 00:30:01 以后才能继续抢购。

Redis 通过队列来维持进程访问共享资源的先后顺序。

Redis 锁主要基于 setnx 函数实现分布式锁，当进程通过 setnx<key,value> 函数返回 1 时，表示已经获得锁。排在后面的进程只能等待前面的进程主动释放锁，或者等到时间超时才能获得锁。

相对于基于数据库实现分布式锁的方案来说，基于缓存实现的分布式锁的优势表现在以下几个方面：

1.性能更好。

2.数据被存放在内存，而不是磁盘，避免了频繁的 IO 操作。

3.很多缓存可以跨集群部署，避免了单点故障问题。

4.很多缓存服务都提供了可以用来实现分布式锁的方法，比如 Redis 的 setnx 方法等。

5.可以直接设置超时时间来控制锁的释放，因为这些缓存服务器一般支持自动删除过期数据。

Redis 的分布式锁的实现

redis setnx, redlock , redisson 实现方案的差别

https://zhuanlan.zhihu.com/p/73807097

基于 ZooKeeper 实现分布式锁

ZooKeeper 的树形数据存储结构主要由 4 种节点构成：

1.持久节点。这是默认的节点类型，一直存在于 ZooKeeper 中。

2.持久顺序节点。也就是说，在创建节点时，ZooKeeper 根据节点创建的时间顺序对节点进行编号。

3.临时节点。与持久节点不同，当客户端与 ZooKeeper 断开连接后，该进程创建的临时节点就会被删除。

4.临时顺序节点，就是按时间顺序编号的临时节点。

根据它们的特征，ZooKeeper 基于临时顺序节点实现了分布锁。

1.在与该方法对应的持久节点 shared_lock 的目录下，为每个进程创建一个临时顺序节点。

2.每个进程获取 shared_lock 目录下的所有临时节点列表，注册子节点变更的 Watcher，并监听节点。

3.每个节点确定自己的编号是否是 shared_lock 下所有子节点中最小的，若最小，则获得锁。例如，用户 A 的订单最先到服务器，因此创建了编号为 1 的临时顺序节点 LockNode1。该节点的编号是持久节点目录下最小的，因此获取到分布式锁，可以访问临界资源。

4.若本进程对应的临时节点编号不是最小的，则分为两种情况：

a. 本进程为读请求，如果比自己序号小的节点中有写请求，则等待；

b. 本进程为写请求，如果比自己序号小的节点中有读请求，则等待。

Rocksdb实现分布式锁

rocksdb merge ?