lease机制

2012-09-12

lease，即租约，是个强大的东西。

lease用于缓存

先看缓存的lease。假设每个client都去server取数据，server可能成为性能瓶颈。然后就有了缓存，client每看看自己有没有相应的缓存，没有才去找server要。但是….有缓存就有server和client的不一致了。比如client A向server发送消息修改了某个东西，然后client B上的缓存就是过期的了。

lease如何解决缓存问题呢？ server给client B缓存颁发一个lease，在lease到期之间，server承诺client B的缓存是有效的。这里client A发消息要求修改，server收到消息后不会执行A的请求，直到lease过期。

lease是很强大的，比如server和B的网络故障了，server可以一直给B重复发那个lease，只要有一次成功，lease都可以生效。如果B一直没收到lease，它就不会使用本地缓存，不影响正确性。

当然，由于lease是按时间点约定的，这就要求各个机器上的时间的一致性。这个不具体讲，不是讨论重点。

lease的本质

上面缓存中的lease机制只是其应用之一。lease的本质是什么呢？

lease本质是颁发者对接受者的一个承诺。在缓存的例子中这个承诺是“在lease有效期内缓存不会过期”。其实这个承诺可以是任何东西，不一定非得是缓存有效时间。

这就非常强大了。 首先，同一个承诺我可以承诺无限多遍。这就是分布式环境中允许消息重复。 然后，这是一个单向的承诺，不要求一定有应答。这就可以解决状态问题。 插讲一下状态问题。分布式系统中是无法确定另一个结点状态的。像TCP三次握手那种机制也不行，我发给你，你应答，我再对应答的确定。谁能保证机器不是把应答确定包刚发出去机器就挂了呢？？ 然后另一边收到应答确认包以为那台机器还是好的，这就是状态问题。所以说，分布式系统中是无法确定另一个结点状态的。

第三，承诺可以是任何东西这一点，让lease可以做很多种事情，可用性大大提高。

lease用于确定状态

先看一个例子。假设有一个master，然后有多个副本。副本中有一个是primiary，其它都是secondary。master用于管理谁是primiary。假设我们用常规的心跳机制，就会出现状态问题。

比如，primiary其实是可以正常工作并提供对client服务的，primiary与其它secondary之间也是OK的，但master和primiary之间连接闪断了。这时master收不到primiary的心跳，就认为primiary挂了，然后重新选择primiary，这样系统中就会出现两个primiary，也就是双主问题。 其实最基本的原因还是单纯用心跳机制master是无法确定结点状态的。

下面就谈lease用于解决结点状态问题。

引用lease机制，master向primary颁发lease，承诺“在这个lease有效期内我不会重新选取primiary”。primiary每个心跳包过来，master就可以颁发新的lease把有效期延长。如果过了lease而master还没收到心跳包，它就认为primiary挂了并重新选择。

这时考虑primiary的两种情况： 第一种，primiary是真的挂了，所以没给master回复。这时重选当然是合理的。 第二种，primiary没挂，只是和master通信出问题了。这时primiary知道自己的lease到期，master肯定在选取新primiary了，于是它就会放弃primiary身份，不会出现双主问题了。

还有一些其它应用。反正lease的机制是很强大的。 工程上lease的有效期一般选择为10秒。