概述

多线程情况下对共享资源的操作需要加锁，避免数据被写乱，在分布式系统中，这个问题也是存在的，此时就需要一个分布式锁服务。常见的分布式锁实现一般是基于DB、Redis、zookeeper。下面笔者会按照顺序分析下这3种分布式锁的设计与实现，想直接看分布式锁总结的小伙伴可直接翻到文档末尾处。

分布式锁的实现由多种方式，但是不管怎样，分布式锁一般要有以下特点：

• 排他性：任意时刻，只能有一个client能获取到锁
• 容错性：分布式锁服务一般要满足AP，也就是说，只要分布式锁服务集群节点大部分存活，client就可以进行加锁解锁操作
• 避免死锁：分布式锁一定能得到释放，即使client在释放之前崩溃或者网络不可达

除了以上特点之外，分布式锁最好也能满足可重入、高性能、阻塞锁特性（AQS这种，能够及时从阻塞状态唤醒）等。
目前业界有三种典型的实现方案：

• 基于DB的分布式锁
• 基于Redis的分布式锁
• 基于Zookeeper的分布式锁

总结

3种分布式锁的设计与实现中，我们可以看出每种实现都有各自的特点，针对潜在的问题有不同的解决方案，归纳如下：

• 性能：redis > zookeeper > db。
• 避免死锁：DB通过应用层设置定时任务来删除过期还未释放的锁，redis通过设置超时时间来解决，而zookeeper是通过临时节点来解决。
• 可用性：DB可通过数据库同步复制，vip切换master来解决，redis可通过集群或者master-slave方式来解决，zookeeper本身自己是通过zab协议集群部署来解决的。注意，DB和redis的复制一般都是异步的，也就是说某些时刻分布式锁发生故障可能存在数据不一致问题，而zookeeper本身通过zab协议保证集群内(至少n/2+1个)节点数据一致性。
• 锁唤醒：DB和redis分布式锁一般不支持唤醒机制（也可以通过应用层自己做轮询检测锁是否空闲，空闲就唤醒内部加锁线程），zookeeper可通过本身的watcher/notify机制来做。

使用分布式锁，安全性上和多线程（同一个进程内）加锁是没法比的，可能由于网络原因，分布式锁服务（因为超时或者认为client挂了）将加锁资源给删除了，如果client端继续操作共享资源，此时是有隐患的。因此，对于分布式锁，一个是尽量提高分布式锁服务的可用性，另一个就是要部署同一内网，尽量降低网络问题发生几率。这样来看，貌似分布式锁服务不是“完美”的。

技术貌似也无法做到十全十美 ，开发人员该如何选择分布式锁呢？最好是结合自己的业务实际场景，来选择不同的分布式锁实现。一般来说，基于redis的分布式锁服务应用较多。

参考资料

1. 分布式锁设计与实现