使用场景
在某些场景中，多个进程必须以互斥的方式独占共享资源，这时用分布式锁是最直接有效的。
分布式锁需满足四个条件
分布式锁需满足四个条件
为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：
- 互斥性。在任意时刻，只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了，即不能误解锁。
- 具有容错性。只要大多数节点正常运行，客户端就能够获取和释放锁。
常见分布式方案
常见分布式锁方案对比
| 分类 | 方案 | 实现原理 | 优点 | 缺点 |
|---|---|---|---|---|
| 基于数据库 | 基于mysql 表唯一索引 | 1.表增加唯一索引2.加锁：执行insert语句，若报错，则表明加锁失败3.解锁：执行delete语句 | 完全利用DB现有能力，实现简单 | 1.锁无超时自动失效机制，有死锁风险2.不支持锁重入，不支持阻塞等待3.操作数据库开销大，性能不高 |
| 基于数据库 | 基于MongoDB findAndModify原子操作 | 1.加锁：执行findAndModify原子命令查找document，若不存在则新增2.解锁：删除document | 实现也很容易，较基于MySQL唯一索引的方案，性能要好很多 | 1.大部分公司数据库用MySQL，可能缺乏相应的MongoDB运维、开发人员2.锁无超时自动失效机制 |
| 基于分布式协调系统 | 基于ZooKeeper | 1.加锁：在/lock目录下创建临时有序节点，判断创建的节点序号是最小。若是，则表示获取到锁；否则watch /lock目录下序号比自身小的前一个节点2.解锁：删除节点 | 1.由zk保障系统高可用2.Curator框架已原生支持系列分布式锁命令，使用简单 | 需单独维护一套zk集群，维保成本高 |
| 基于缓存 | 基于redis命令 | 1. 加锁：执行setnx，若成功再执行expire添加过期时间2. 解锁：执行delete命令 | 实现简单，相比数据库和分布式系统的实现，该方案最轻，性能最好 | 1.setnx和expire分2步执行，非原子操作；若setnx执行成功，但expire执行失败，就可能出现死锁2.delete命令存在误删除非当前线程持有的锁的可能3.不支持阻塞等待、不可重入 |
| 基于缓存 | 基于redis Lua脚本能力 | (见附) | 同上；实现逻辑上也更严谨，除了单点问题，生产环境采用用这种方案，问题也不大。 | 不支持锁重入，不支持阻塞等待 |
附lua 脚本
加锁脚本：
1. 加锁：执行 SET lock_name random_value EX seconds NX 命令
解锁脚本：
random_value
-- ARGV[1]为random_value, KEYS[1]为lock_name
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end