分布式锁实现方案

一、数据库

创建一个分布式锁表，加锁后，我们就在表增加一条记录，释放锁即把该数据删掉。

缺陷：

1. 没有失效时间，容易导致死锁，只能自己写定时任务检查；
2. 依赖数据库的可用性，一旦数据库挂掉，锁就马上不可用，得实现数据库高可用；
3. 这把锁只能是非阻塞的，因为数据的 insert 操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作，自己实现阻塞自旋；
4. 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据库中数据已经存在了，可以通过记录线程标识解决。

二、Redis

SETNX(SET If Not Exists)：当且仅当 Key 不存在时，则可以设置，否则不做任何动作。
SETEX：可以设置超时时间
其原理为：通过 SETNX 设置 Key-Value 来获得锁，随即进入死循环，每次循环判断，如果存在 Key 则继续循环，如果不存在 Key，则跳出循环，当前任务执行完成后，删除 Key 以释放锁。

key : 设置为要锁的资源标识
value: 设置为加锁的线程id ,防止锁被其他线程误释放。
设置超时时间：防止死锁。
使用WatchDog机制：实现锁延期，防止超时时间过短，业务未执行完锁就失效。

# 添加锁 利用setnx的互斥特性
    SETNX lock thread1
# 添加锁过期的时间，避免服务宕机引起的死锁
    EXPIRE lock 5
# 添加锁，NX是互斥，EX是设置超时时间 (使其具有了原子性)(最终命令)
    SET lock thread1 NX EX 10
# 释放锁
    DEL key

多节点 Redis 实现分布式锁：保证可靠
Redlock：
实现高可靠的分布式锁，不能仅依赖单个的命令操作了，需要按照一定的步骤及规则进行加解锁，以避免 Redis 实例故障而导致锁无法工作的问题，即分布式锁算法。由 Redis 开发者 Antirez 提出了分布式锁算法 Redlock。
Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，若客户端能够和半数以上的实例成功地完成加锁操作，那么就认为，客户端成功地获得分布式锁了，否则加锁失败。

这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。

Redlock 算法的实现需要有 N 个独立的 Redis 实例。接下来可以分成 3 步来完成加锁操作：

1. 客户端获取当前时间。

2. 客户端按顺序依次向 N 个 Redis 实例执行加锁操作。每个实例加锁步骤与上面单实例操作一致，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标志。保证某个实例故障时加解锁仍可用，需要对加锁设置设置超时时间。若客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

3. 一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。客户端只有在满足以下两个条件时，才能认为加锁成功。

    1.客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
    2.客户端获取锁的总耗时没有超过锁的有效时间。
   

满足上述第三部中的两个条件后，就需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。若锁的有效时间已经来不及完成共享数据的操作了，可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。
如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那客户端向所有 Redis 节点发起释放锁的操作。

在 Redlock 算法中，释放锁的操作和在单实例上释放锁的操作一样，只需执行释放锁的 Lua 脚本即可。这样以来，只要 N 个 Redis 实例中的半数以上实例能正常工作，就能保证分布式锁的正常工作了。

成熟方案: Redisson .

缺陷：redis master-slave 架构的主从异步复制导致的 redis 分布 式锁的最大缺陷：在 redis master 实例宕机的时候，可能导致多个客户端同时完成加锁。

三、Zookper

实现原理为：

1. 建立一个节点，假如名为 lock 。每当进程需要访问共享资源时，会调用分布式锁的 lock() 或 tryLock() 方法获得锁，这个时候会在第一步创建的 lock 节点下建立相应的顺序子节点，节点类型为临时顺序节点（EPHEMERAL_SEQUENTIAL），通过组成特定的名字 name+lock+顺序号。
2. 在建立子节点后，对 lock 下面的所有以 name 开头的子节点进行排序，判断刚刚建立的子节点顺序号是否是最小的节点，假如是最小节点，则获得该锁对资源进行访问。假如不是该节点，就获得该节点的上一顺序节点，并监测该节点是否存在注册监听事件。同时在这里阻塞。等待监听事件的发生，获得锁控制权。
3. 当调用完共享资源后，调用 unlock() 方法，进而可以引发监听事件，释放该锁。实现的分布式锁是严格的按照顺序访问的并发锁。

Zookeeper实现的分布式锁存在两个个缺点：

（1）性能上可能并没有缓存服务那么高，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。

（2）zookeeper的并发安全问题：因为可能存在网络抖动，客户端和ZK集群的session连接断了，zk集群以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。