介绍
说到分布式锁,网上有很多实现,比如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选举 保障主的可用存在。
接口设计与思维
根据要求,可以设计出锁接口,首先锁的基本方法&