从分布式理论到如何做一个生产级别的分布式锁

前言

微服务的流行，使得现在基本都是分布式开发，也就是同一份代码会在多台机器上部署运行，此时若多台机器需要同步访问同一个资源（同一时间只能有一个节点机器在运行同一段代码），就需要使用到分布式锁。然而做好一个分布式锁并不容易，要考虑的点非常多，建议架构能力一般的公司对于分布式锁还是使用现有的开源框架来做（例如Redis的Redisson、Zookeeper的Curator、etcd等等），如果需要基于Redis、ZK进行自研的话，建议阅读接下来讨论的几个要点。

1. AP还是CP？

首先我觉得最重要的就是考虑分布式协议的CAP特性，因为这直接决定了分布式锁的强弱、性能的强弱，详细的CAP理论到分布式一致性协议的讨论请点击访问，接下来看看AP、CP模型的分布式锁都将会有哪些表现

1.1 CP模型

这里CP模型我选用了Zookeeper（Zab协议）做例子，其实Etcd的Raft算法也是一个道理，但是我没用过Etcd…

首先，Zab和Raft是如何保证CP模型呢？没有这个基础的读者建议火速浏览这篇文章，这里只讨论优点和可能存在的某些问题。

主要是由图1的数据复制规则+图2的选举主节点规则结合起来，使得Set的数据在集群半数节点以上存活的时候一定不会丢，保证了数据一致性，但是如果集群半数以上节点宕机，集群将不对外服务，查询不到值，也是一种一致性的体现（不给总比给错乱给好，至少在分布式锁场景下是这样，不加锁总比锁失效强吧？）

CP模型存在的问题？

从图3的数据复制规则来看，客户端要求Set一个值的时候并没有立即返回，而是需要确保这个值在半数以上的节点上保存下来了才会返回给客户端成功响应，这样的话延时性就取决于最快的那半数节点的写入性能，而且加多了网络通信来回的开销，在一定程度上延时性会弱一些，框架如果在高并发场景下可能会出现性能下滑（Zookeeper）的结果，这也就是为什么Zookeeper作为注册中心不被看好的原因，微服务链路调用都需要使用注册中心获取服务的IP地址，并发量可见一斑，但IP地址这种东西小概率存在不一致（服务刚上线，但注册中心没有这个服务的IP地址，使得不被访问到）其实是可以接受的，在注册中心的场景下延时性才最重要，这也就是为什么Nacos的注册中心会选用我们接下来要讨论的AP模型，他的延时性相对是要好的。

但是如果在不容许分布式锁失效且并发量、性能要求不是特别严格的场景下，这种CP模型是再合适不过了。

1.2 AP模型

这里AP模型我选用了Redis的主备集群做例子

首先，为什么Redis的主备是AP模型？

从图3可以看出来，redis的主备复制采用了异步增量复制（在新的节点启动时会全量+增量优化启动复制的时间，这里不讨论全量+增量模式），主Master节点设置值之后立刻就会返回给客户端OK信息，接下来增量复制值给Slave从节点

试想一下，若在第三步返回给客户端OK信息后主Master节点宕机了，数据没来得及复制给Slave从节点，此时Sentinel哨兵会选择一个从节点成为Master主节点，由图4可以看出，不管我们此时选择哪个节点做为Master，刚刚设置的值确实是丢失了，这里就造成了不一致，这种主从集群架构会丢失或不一致主节点宕机的一段时间的数据

AP模型的好处？

但这种模型有什么好处呢？又或者说Redis的主备设计成AP模型有什么考量呢？我们结合上面的CP模型来看，可以发现在接受事务请求（增删改数据）的时候，主Master节点只需要确保自己写入即可立即返回给客户端，复制的过程由于是异步的，客户端延时性上来说影响并不大，相比于CP模型的确保半数提交成功，AP模型的延时性是比较低的，Redis本身的定位就是要快，所以这相当符合Redis的设计初衷。再来看看可用性，如果集群有三个节点，他可以容许宕机两个节点，可以看出来，可用性的容错节点是N-1个，相比于CP模型他的可用性会更高，Redis的定位不就是缓存（快+高可用+数据丢失一部分可以接受）吗？

RedLock

那么有没有办法解决Redis主从这种不一致呢？这就是将要介绍的RedLock所做的事，其思想其实和CP模型一样，基于至少3个独立的Redis实例，获取锁的时候要分别访问三个Redis获取锁，半数以上的Redis返回获取锁成功后才能算获取到锁（这不是和CP一样吗？），保证了数据一致性，但是却带来了额外的延时性（要访问3个或以上的Redis服务，也存在网络开销），额外的后期运维复杂性（要多个独立的Redis实例），笔者个人觉得ÿ