为什么说“分布式锁”是个大坑？

在我日常的工作实际中，一个原则就是“尽一切可能避免使用分布式锁，能不用就尽量不用”。因为分布式锁，实在有“太多坑”。

1. 用ZK实现

（1）性能不够。每秒QPS最多几千，高并发场景下，这会成为整个系统的瓶颈。

（2）极端情况，2个进程会拿到同一把锁：因为用心跳探测客户端是否宕机，当网络超时或客户端发生Full GC的时候会产生误判。本来客户端没有宕机，却误判为宕机了，锁被释放，然后被另外一个进程拿到，从而导致两个进程拿到同一把锁。

 2. 用Redis实现

（1） Redis发生主从切换，可能部分锁的状态数据丢失。

（2）客户端释放锁之前，宕机，导致锁永远不能得到释放。为了能释放，需要给锁加入一个超时机制。

（3）加了超时机制之后，又会出现跟上面同样的问题，2个进程拿到同一把锁。

3. 用Mysql实现

 跟用Redis实现，同样问题

4. 为此，Redis作者发明了一个RedLock，希望用集群多数派选举的方式，实现分布式锁。

这个RedLock，也引发Redis作者和另外一位分布式大牛，也是《数据密集型应用系统设计》这本书的作者的一番辩论，也是认为这个RedLock有各种缺陷。后续专门写篇文章来讨论，RedLock到底有哪些缺陷。

所以，搞来搞去会发现并没有一个“没有漏洞”的分布式锁方案，最终我的策略是：应用层面串行化，尽可能避免分布式锁的使用。

关于如何串行化，可以看另外一篇讲“并发更新“的文章。