Redis学习18-分布式锁
Redis 分布式锁
什么是分布式锁?
在分布式系统中，会涉及到多个节点访问同一个公共资源的情况
Redis 分布式锁是使用一个公共的服务器，来记录加锁状态。
这个公共的服务器可以是 Redis，也可以是其他组件（比如 MySQL 等），还可以是我们自己写的服务
分布式锁的基础实现
通过一个键值对来标识锁的状态。
例子：
考虑买票的场景，现在车站提供了若干个车次，每个车次的票数都是固定的。
现在存在多个服务器节点，都可能需要处理这个买票的逻辑：先查询指定车次的余票，如果余票 > 0，则设置余票值 -= 1。
上述的场景是存在“线程安全”问题的，需要使用锁来控制。如果不控制就可能出现“超卖”
加锁：
可以引入一个 Redis，作为分布式锁的管理器。
此时，如果买票服务器1 尝试买票，就需要先访问 Redis，在 Redis 上设置一个键值对。比如 key 就是车次，value 设置个值（比如 1）
如果这个操作设置成功，就视为当前没有节点对该 001 车次加锁，就可以进行数据库的读写操作。操作完成之后，再把 Redis 上刚才的这个键值对给删除掉。
如果在买票服务器1 操作数据库的过程中，买票服务器2 也想买票，也会尝试给 Redis 上写一个键值对，key 同样是车次。但是此时设置的时候发现该车次的 key 已经存在了，则认为已经有其他服务器正在持有锁，此时服务器2 就需要等待或者暂时放弃。
Redis 中提供了
setnx操作，正好适合这个场景。即：key 不存在就设置，存在则直接失败。
引入过期时间
当服务器1 加锁之后，开始处理买票的过程中，如果服务器1 意外宕机了，就会导致解锁操作（删除该 key）不能执行。就可能引起其他服务器始终无法获取到锁的情况。
为了解决这个问题，可以在设置 key 的同时引入过期时间。即这个锁最多持有多久，就应该被释放。
可以使用
set ex nx的方式，在设置锁的同时把过期时间设置进去。
注意：
如果分开多个操作，比如
setnx之后，再来一个单独的expire，由于 Redis 的多个指令之间不存在关联，并且即使使用了事务也不能保证这两个操作都一定成功，因此就可能出现setnx成功，但是expire失败的情况。
此时仍然会出现无法正确释放锁的问题。
引入校验 id
对于 Redis 中写入的加锁键值对，其他的节点也是可以删除的。
比如服务器1 写入一个 “001”: 1 这样的键值对，服务器2 是完全可以把 “001” 给删除掉的。
当然，服务器2 不会进行这样的“恶意删除”操作，不过不能保证因为一些 bug 导致服务器2 把锁误删除。
此时可以引入一个校验 id。
比如可以把设置的键值对的值，不再是简单的设为一个 1，而是设成服务器的编号。形如 “001”: “服务器1”。
这样就可以在删除 key（解锁）的时候，先校验当前删除 key 的服务器是否是当初加锁的服务器，如果是，才能真正删除；不是，则不能删除。
引入 Lua 脚本
为了使解锁操作原子，可以使用 Redis 的 Lua 脚本功能。
Lua 的语法类似于 JS，是一个动态弱类型的语言。Lua 的解释器一般使用 C 语言实现。Lua 语法简单精炼，执行速度快，解释器也比较轻量（Lua 解释器的可执行程序体积只有 200KB 左右）。
因此 Lua 经常作为其他程序内部嵌入的脚本语言。Redis 就支持 Lua 作为内嵌脚本。
使用 Lua 脚本完成上述解锁功能：
if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1])
elsereturn 0
end;
引入 watch dog (看门狗)
当我们设置了 key 过期时间之后（比如 10s），仍然存在一定的可能性，当任务还没执行完，key 就先过期了。这就导致锁提前失效。
动态的调整时间更合适。（过期时间的续约问题）
watch dog，就是加锁的服务器上的一个单独的线程，通过这个线程来对锁过期时间进行“续约”。
注意，这个线程是业务服务器上的，不是 Redis 服务器的。
举例：
初始情况下设置过期时间为 20s。同时设定看门狗线程每隔 5s 检测一次。
那么当 5s 时间到的时候，看门狗就会判定当前任务是否完成。
- 如果任务已经完成，则直接通过 lua 脚本的方式，释放锁（删除 key）。
- 如果任务未完成，则把过期时间重写设置为 10s。（即“续约”）
心锁提前失效的问题就得以解决。同时如果该服务器挂了，看门狗线程也就随之挂了，此时无人续约，这个 key 自然就可以迅速过期，让其他服务器能够获取到锁了。
其他
上述锁只是一个简单的互斥锁。还有一些其他特殊的锁，比如：可重入锁、公平锁、读写锁