不要使用分布式锁 就像Martin Fowler说的那样，“分布式调用的第一原则就是不要分布式”，谈分布式锁也要先说，不要使用分布式锁。原因很简单，分布式系统是软件系统中复杂的一种形式，而分布式锁是分布式系统中复杂的一种形式，没有必要的复杂性就不要引入。 有的逻辑是没有副作用的（纯函数代码），那就可以无锁执行；有的数据经过合理的sharding之后，可以使用单线程（单节点）执行，那就单线程执行。 比如一种常见的模式就是使用queue（比如Kafka），任务全部放到队列中，然后根据sharding的逻辑，不同的consumer来处理不同的任务，互相之间不会干扰冲突。 还有一个例子是Kotlin Coroutine，通过指定一个单线程的dispatcher，也可以保证它执行的操作之间互相不会有多线程的冲突问题。 有了这样的原则以后，再来谈谈几种分布式锁。 数据库锁 分布式系统中，我觉得我们最常见的锁就是使用一个中心数据库来做的。 一种是悲观锁，就是“select xxx ... for update”这样的，相应的数据行会被锁上，直到commit/rollback操作发生。如果被别人锁了，当前线程没得到锁的话就会等着。 还有一种是乐观锁，就是使用版本号，“update ... where ... version=A”这样的。如果update成功，表示获取锁成功，并且操作也成功；否则就是update失败，需要重新获取状态再来操作一遍。 大多数情况下，后者要更高效一些，因为阻塞的时间通常更短，不过在锁竞争比较激烈的情况下，反而效率会反过来。另外一个，悲观锁代码写起来会容易一些，因为select语句执行和commit/rollback是两步操作，因此二者之间可以放置任意逻辑；而乐观锁则是需要把数据的写操作和version的比较放在一条语句里面。 这两种都很常见，基本上我接触过的一半以上的项目都用过两者。这个数据库不一定非得是关系数据库，但是强一致性必须是保证的。 S3 使用S3来创建文件，让创建成功的节点得到锁，文件里面也可以放自定义的内容。我们去年的项目用到这个机制。这种方式是建立在S3 2020年12月1日，上线的strong consistency的feature。 大致上，有这样两种思路： 使用S3 versioning，就是说，在versioning打开的情况下，文件的写入不会有“覆盖”的情况发生，所有内容都会保留。在创建文件的时候，response种会有一个x-amz-version-id header。节点写入文件后，再list一下所有的version，默认这些version会根据创建的时间顺序递减排列，后创建的在前，因此比较其中最早的那个version和自己创建文件后得到的version，如果两者相等，说明自己得到了锁。 使用S3 Object Lock，这个可以控制让第一次写成功，后面的操作全部失败，所以第一次写入成功的节点得到锁。 使用这种方式，对于那些本来就需要使用S3文件系统来共享任意信息的情况很方便，但是需要自己处理超时的问题，还有retention策略（该不该/什么时候删掉文件）。 Redlock Redlock就是Redis的锁机制。Martin Kleppmann（就是那个写《Design Data-Intensive Applications》的作者）几年前写过一篇文章，来吐槽Redlock在几种情况下是有问题的： Clock jump：Redlock依赖于物理时钟，而物理时钟有可能会跳（jump），并且这种状况是无法预测的。Clock jump就是说，始终会不断进行同步，而同步回来的时间，是有可能不等于当前时间的，那么系统就会设置当前时间到这个新同步回来的时间。在这种情况下，依赖于物理时间的锁逻辑（比如超时的判断等等）就是不正确的。 Process pause：得到锁的节点，它的运行是有可能被阻塞的。比如GC，下面这个图说的就是这个情况——client 1一开始得到锁了，执行过程中有一个超长时间的pause，这个pause导致锁超时并被强制释放，client 2就得到锁了，之后client 1 GC结束，缓过来后恢复执行，它却并没有意识到，它的锁已经被剥夺了，于是client 1和client 2都得到了锁，对于数据的修改就会发生冲突。 Network delay：其实原理和上面差不多，网络延迟+锁超时被强制剥夺和重分配的逻辑，在特定情况下就是不正确的。 问题可以理解，可是仔细想想这个问题的本质是什么？它的本质其实就是消息延迟+重排序的问题，或者更本质地说，就是分布式系统不同节点保持consistency的问题，因为lock service和client就是不同的节点，lock service认为之前的锁过期了，并重分配锁给了client 2，并且client 2也是这样认为的，可是client 1却不是，它在GC之后认为它还持有者锁呢。 如果我们把数据的写操作和锁管理的操作彻底分开，这个问题就很难解决，因为两个节点不可能“一直”在通信，在不通信的时间段内，就可能会发生这种理解不一致的情况。但是如果我们把写操作和锁管理以某种方式联系上，那么这个问题还是可以被解决的。简单说，就是物理时钟不可靠，逻辑时钟可以解决这个问题。 之后Martin Kleppmann提出了解决方案，他的解决方案也就是按照这个思路进行的。他的方法很简单，就是在获取锁的时候，得到一个永远递增的token（可以被称作“fencing token”），在执行写操作的时候，必须带上这个token。如果storage看到了比当前token更小的token，那么那个写操作就要被丢弃掉。 Chubby Chubby是Google的分布式锁系统，论文在这里可以找到，还有这个胶片，对于进一步理解论文很有帮助。从时间上看，它是比较早的。 Chubby被设计成用于粗粒度的（coarse-grained）锁需求，而非细粒度（fine-grained，比如几秒钟以内的）的锁需求。对于这样一个系统，文中开始就提到consistency和availablity重要性要大过performance，后面再次提到首要目标包括reliability，能够应对较多数量的clients，和易于理解的语义，而吞吐量和存储容量被列在了第二位。 Chubby暴露一个文件系统接口，每一个文件或者文件夹都可以视作一个读写锁，文件系统和Unix的设计思路一致，包括命名、权限等等的设计都是基于它。这是一个很有意思的设计。 对于一致性的达成，它使用Paxos，客户端寻找master和写数据都使用quorum的机制，保证写的时候大部分节点成功，而读的时候则是至少成功读取大部分节点（R+W>N，这个思路最早我记得是Dynamo的论文里面有写）；如果lock有了变化，它还提供有通知机制，因为poll的成本太高。 内部实现上面，每一个Chubby的cell都是由作为replica的5个服务节点组成，它们使用Paxos来选举master和达成一致，读写都只在master上进行（这个看起来还是挺奢侈的，一个干活，四个看戏）。如果master挂掉了，在master lease过了以后，会重新选举。Client根据DNS的解析，会访问到该cell里面的某一个节点，它不一定是master，但是它会告知谁是master。 分布式锁里面比较难处理的问题不是失败，而是无响应或者响应慢的超时问题。Chubby采用一种租约的机制，在租约期内，不会轻易变动当前的master节点决定。在响应超时的时期，客户端的策略就是“不轻举妄动”，耐心等待一段时间等服务端恢复，再不行才宣告失败： 这个图的大致意思是，第一次租约C1续订没有问题；第二次租约续订C2了之后，原来的master挂了，心跳请求无响应，这种情况客户端不清楚服务端的状况，就比较难处理，于是它只能暂时先阻塞所有的操作，等到C2过期了之后，有一个grace period；接着再grace period之内，新的master被选举出来了，心跳就恢复了，之后租约续订的C3顺利进行。 这显然是一个异常情形，但是一旦这种情况发生，系统是被block住的，会有非常大的延迟问题。思考一下，这种情况其实就是从原来的master到新的master转换的选举和交接期间，锁服务是“暂停”的。再进一步，这个事情的本质，其实就是在分布式系统中，CAP原理告诉我们，为了保证Consistency和Partition Tolerance，这里的情形下牺牲掉了Availability；同时，为了保证consistency，很难去兼顾performance（latency和throughput）。 此外，有一个有点反直觉的设计是，Chubby客户端是设计有缓存的。通常来讲，我们设计一个锁机制，第一印象就是使用缓存会带来复杂性，因为缓存会带来一致性的难题。不过它的解决办法是，使用租约。在租约期内，服务端的锁数据不可以被修改，如果要修改，那么就要同步阻塞操作通知所有的客户端，以让缓存全部失效（如果联系不上客户端那就要等过期了）。很多分布式系统都是采用poll的方案——一堆client去poll一个核心服务（资源），但是Chubby彻底反过来了，其中一个原因也是低throughput的考虑，毕竟只有一个master在干活。 对于前面提到的Martin Kleppmann谈到的那个问题，Chubby给了两个解决方法： 一个是锁延迟，就是说，如果一切正常，那么持有锁的客户端在释放掉锁之后，另外的客户端可以立即获取锁。但是如果出现超时等等异常，这个锁必须被空置一段时间才可以被分配。这个方法可以降低这个问题出现的概率，但是不能彻底规避问题。 第二个就是使用序列号了，对于写入操作来说，如果请求携带的序列号要小于前一次写入的序列号，那就丢弃请求，返回失败。 回过头思考Chubby的实现机制，我觉得有这样几个启发： 不要相信任何“人”（节点），必须询问到多数人（quorum），多数人的结论才可以认为是正确的。这个方式发生在很多操作上，比如寻找master，比如选举master，比如写数据。 超时是很难处理的，它采用了租约的机制保证节点丢失时间的上限，使用grace period来容忍master选举发生的时延，使用序列号来保证正确性。