etcd 访问 锁_分享分布式锁选型背后的架构思维(带源码)

介绍

说到分布式锁，网上有很多实现，比如redis 分布式锁、zk分布式锁、etcd分布式锁等等。但是那么多选择，哪个适合你 或者说 适合你的项目呢？这个就需要分析了，只有分析后才能找到最合适的分布式锁。分析业务，得到业务本质，就是架构思维；思维最终是需要落地的，接下去我分享一下对分布式锁的思考和实践。

锁的本质是对共享资源的处理，表现也很多，笔者总结了下这些表象为作用：

业务协调

业务幂等(需配合业务代码实现)

共享资源竞争

在单体应用时代表现为的就是同步块，lock。随着需求和业务量的增长，系统走向了分布式、微服务时代，多服务/多实例下的应用无法使用本地锁进行控制资源共享。这时就出现了分布式锁，我分析了分布式场景下的情况，可以归纳出分布式锁的要求：

强一致性

服务高可用、系统稳健

锁自动续约、自动释放

业务可重入

选型及场景

目前网上常见分布式锁的实现有redis、zookeeper、etcd，先来个总体比较。

接下来，咱们对比较指标进行一一解释：

一致性算法CAP：在分布式场景下，CAP理论是很多设计的指导思想。CAP思想下有两个分支，cp与ap；cp：不管啥情况下，都要求各服务之间的数据一致；AP：高可用下的数据最终一致性。虽然锁原本要求强一致性，但基于CAP理论也对AP有了一定的容忍度。AP分布式锁的使用取决于 业务场景对 脏数据的最大容忍度，比如SNS场景，这时AP锁存在，从性能上有很大的优势。CP仍然保持原有的一致性要求，保证了业务资源串行竞争，更加适合于金融交易场景的强数据要求。redis自身无一致性算法来保证多节点的数据一致性，所以是AP模式；zk、etcd都有一致性算法，所以都是CP模式。

高可用：redis是一个k-v的存储；使用主从模式进行集群，redis-cluster 底层也是主从模式的组合；性能高，也保证了靠可用。zk是tree的数据结构，节点要求N+1，N必须大于2；通过 ZAB选举 保障主的可用。etcd是一个k-v的存储，节点要求N+1，N必须大于2；通过 raft选举 保障主的可用存在。

接口设计与思维

根据要求，可以设计出锁接口，首先锁的基本方法&