| 基于数据库 |
基于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脚本能力 |
1. 加锁：执行SET lock_name random_value EX seconds NX 命令2. 解锁：执行Lua脚本，释放锁时验证random_value -- ARGV[1]为random_value, KEYS[1]为lock_nameif redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end |
同上；实现逻辑上也更严谨，除了单点问题，生产环境采用用这种方案，问题也不大。 |
不支持锁重入，不支持阻塞等待 |
|