场景
修改时，经常需要先将数据读取到内存，在内存中修改后再存回去。在分布式应用中，可能多个进程同时执行上述操作，而读取和修改非原子操作，所以会产生冲突。增加分布式锁可以解决这个问题
基本原理
- 同步锁：在多个线程都能访问到的地方，做一个标记，标识该数据的访问权限
- 分布式锁：在多个进程都能访问到的地方，做一个标记，标识该数据的访问权限
实现方式
- 基于数据库
- 基于Redis
- 基于zookeeper
分布式锁的原则
- 安全属性：独享。在任意时刻，只有一个客户端持有锁
- 活性A：无死锁。即便持有锁的客户端崩溃或者网络被分裂，锁仍然可以被获取
- 活性B：容错。只要大部分Redis节点都活着，客户端就可以获取和释放锁。
单Redis实例实现分布式锁
- 获取锁使用命令
SET lock_key unique_value NX PX 10000
lock_key 就是 key 键；
unique_value 是客户端生成的唯一的标识，区分来自不同客户端的锁操作；
NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
PX 10000 表示设置 lock_key 的过期时间为 10s，这是为了避免客户端发生异常而无法释放锁。
2. 使用lua脚本释放锁：
// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
要保证删除锁的客户端就是加锁的客户端。所以，解锁的时候，我们要先判断锁的 unique_value 是否为加锁客户端，是的话，才将 lock_key 键删除。比如以下情况：
| A | B |
|---|---|
| 加锁 | |
| 阻塞 | |
| 因超时而释放锁 | 加锁 |
| 恢复 | |
| 解锁（此时把B的锁解开了） | |
| 可以看到，解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性，因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，保证了锁释放操作的原子性。 |
多Redis实例实现分布式锁
