- 产生背景
服务器集群模式下需要对临界资源实现互斥访问 - 实现方案
- 基于数据库
使用唯一索引或排他锁来实现。
缺点是IO限制导致的性能较差，同时支持功能太少，需要额外开发锁超时、锁失效等功能。 - 基于KV缓存
一般通过redis来实现。
一种是单机方案，即通过单个redis实例，set key value ex/px timeout nx语句实现加锁，通过lua脚本比较key和value实现解锁，通过watchDog看门狗来实现业务运行时间超过“锁超时时间”时的续期，该方案问题在于单点故障问题；
另一种是哨兵模式方案， 通过引入主从架构和哨兵机制，提升了系统的鲁棒性，但仍然会有主从切换时分布式锁可能被同时获取、以及由于网络原因导致的“脑裂”（多个master节点）等问题；
第三种是RedLock方案，通过多个并列的redis实例提升系统的鲁棒性，加锁时需要对每个redis实例都加锁，只有超过一半的实例都加锁成功才算加锁成功。这种方案极大恶化了性能，同时在一些边界情况如某个redis实例中的锁过期时客户端在GC导致仍然在使用锁等场景仍然有问题 - 基于一致性协议
一般通过zookeeper实现，主要借助临时有序节点和watcher机制，客户端在获取锁时，会在zookeeper中创建一个临时有序节点（先创建的节点序号更小，优先级更高），序号最小的节点能获取到锁，同时通过watcher机制观察节点状态，当客户端解锁时，对应的临时有序节点会在zookeeper中注销，watcher观察到节点注销后，会通知下一个序号最小的节点获取到锁。
zookeeper是鲁棒性最强的方案，但是在一些极边界情况下，仍然有问题，比如客户端网络异常会导致对应临时有序节点被注销，这样就会有新的客户端能拿到锁，可能就造成了锁被同时持有。
- 方案选型
- 对性能没要求，对分布式锁的功能需求也极简单，可以考虑数据库方案，但一般不建议。
- 对性能要求高，允许极端情况容错，可以采用Redis的方案。
- 对性能要求较高，同时对一致性要求相当严格，可以采用zookeeper的方案。
