分布式入门之1：Lease机制

引子：

分布式系统中，如何确认一个节点是否工作正常？

 

如果有3副本A、B、C，并通过中心结点M来管理。其中A为主副本。

未接触过分布式的直观的处理方法是在每个副本与中心节点M中维护一个心跳，期望通过心跳是否存在而判断对方是否依旧存活。

心跳方法其实根本无法解决分布式下的这个问题。考虑如下场景：

M在某时刻未能预期收到主节点A的心跳，M认为A已经异常，于是从B、C中选取一个B作为主节点。但实际上A并未异常，而是由于网络瞬时阻塞、或是M本身出现异常使A这消息暂时未收到。这时，系统中出现A、B两个都是主节点的情况，称“双主”问题，从节点C可能同时从这两个主节点同步数据，这会引发很严重的数据错误。

因此，需要更合理的机制来判断节点是否正常工作。

 

 

主要思路有两种：一是设计能容忍双主的分布式协议，二是用lease机制。

一涉及去中心化，不讨论。

 

lease的原理：

lease的思想非常简单，既然中心节点需要获取目标节点是否异常的情况，同时又要考虑网络出问题等异常，那就干脆考虑各种异常情况在内，只单方面给对方一个期限，在这个期限内，我认为你是正常的，不正常也认为正常。超出这个期限，我就认为你异常了。由于网络延迟等原因，这个期限不能使用相对时间，而必须使用绝对时间。比如，1点之间，节点A就是主节点。这样就能避免双主问题。节点A为如果收到这个lease，即得到了中心节点的授权，1点前绝对只有自己是主。心跳依旧照发，只是每次中心节点都只根据lease是否有效来判断节点状况，不会出问题。

 

lease是一种颁发的带期限的承诺，有两方面的意义：颁发者在承诺期限内一定遵守承诺，被颁发者在承诺期限内可放心行使承诺的内容；期限过了以后，被颁发者一定不可再行使承诺。

 

lease与活锁

lease的颁发往往是被动的，比如A节点需要中心节点的某个承诺，比如读并缓存，则会向中心节点请求lease，中心节点回复最新可缓存的数据与一个lease，在此lease期限内，中心节点保证目标节点缓存内容与中心节点一致。

按lease方案，如果中心节点需要修改对应数据，必须等全部lease失效。问题是等lease失效的过程中，可能有新的请求元数据的请求到达，这时中心节点又会继续颁发新的lease，使得lease一直不结束，形成“活锁”，即修改请求等待lease失效，而又源源不断颁发新lease而一直无法完成。

解决活锁的办法：当有修改请求在等待着lease失效时，如果后续有读请求，则只返回请求数据而不颁发新lease，或者是只颁发目前最长的lease。

解决活锁后，修改请求仍然需要等待全部lease结束，写请求可能阻塞太久。可以在写请求到达时，中心节点主动给各节点发取消lease的消息。如果全部正确返回，则写可立即进行。如果有异常，那就正常等待lease结束。

 

lease的容错：

由于仅依赖于绝对时间，因此lease机制天生即可容忍网络、lease接收方的出错。

对于中心节点异常，比如宕机，只需要在颁发者恢复后，等待一个最大lease期限就可保证所有lease失效；另一方面，颁发者宕机可能使得全部节点没有lease，系统处于不可用状态，解决的方法就是使用一个小集群而不是单一节点作为颁发者。

颁发者与被颁发者之间的时钟可能也存在误差，只需要颁发者考虑时钟误差即可。

lease时间长短一般取经验值10秒。太短网络压力大，太长则收回承诺时间过长影响可用性。

 

应用：

GFS中，Master通过lease机制决定哪个是主副本，lease在给各节点的心跳响应消息中携带。收不到心跳时，则等待lease过期，再颁发给其他节点。

Niobe中，主副本持有从副本颁发的lease，当lease过期时，主从分别会在中心节点上标记对方不可用，而中心节点是全局一致的，两者只有一个会成功。如果主成功了，从不可用，需要重新与主同步才能可用；如果从成功了，则自己成为新主。

chubby中，paxos选主后，从节点会给主颁发lease，在期限内不选其他节点为主。另一方面，主节点给每个client节点发送lease，用于判断client死活。

zookeeper中，选主不用lease，而是直接发现没有主则选主。其余和chubby一致。

 

http://blog.csdn.net/mindfloating/article/details/7903219