租约机制详解

这篇文章介绍了租约机制详解，分享给大家做个参考，收藏极客之家收获更多编程知识

概述

租约机制指在租约期限内，拥有租约的节点有权利操作一些预设好的对象，具体如下

1. 租约是由授权者授予的一段时间内的承诺
2. 授权者一旦发出租约，则无论接受方是否收到，也无论后续接收方处于何种状态，只要租约不过期，授权者就得遵守承诺，按承诺的时间和内容执行。
3. 接收方在有效期内可以使用授权者的租约，如果租约过期，那么授权者将不再对租约的承诺负责。如果要继续使用租约，则需要重新申请。
4. 可以通过版本号、时间周期或者某个固定的时间点判断租约是否有效

可以把租约机制和公司的权利下放做类比来帮助理解。公司有董事会、CEO、CTO 和 CFO，董事会把公司不同的管理权限在一定时间内分别授权 CEO、CTO、CFO，在固定的时间段内如果有相关事宜，则直接找 CEO、CTO、CFO 处理，不必所有事情都要经过董事会，因为董事会已经授权了 CEO、CTO、CFO 在部分时间段内拥有相关事宜的执行权限，而在该时间段内董事会不能违约，因此 CEO、CTO、CFO 可以按照线定执行相关权利，在约定的时间到期后，CEO、CTO、CFO 需要考虑是续约还是解约

租约机制解决的问题

1. 分布式系统节点的状态变化

目前，大部分分布式系统都是采用主备的方式来实现的，一般主节点负责集群的管理工作，同时负责数据的写操作并将数据同步到各个备节点。备节点接收用户的读操作，当当主节点发生宕机时，从备节点中选举出一个主节点，继续为系统服务

那么集群中的各个节点是如何确定其他节点状态的呢？答案是通过心跳机制。假设有三个节点，分别为 Server-1、Server-2、Server-3，它们之间互为副本，其中 Server-1 为主节点，Server-2、Server-3 为备节点。另一个节点 Server-Electer 负责判断节点状态，在发现主节点异常后，会从备节点重新选出一个主节点继续为集群服务。

Server-Electer 通过心跳机制定时与其他节点通信，如果超过一段时间收不到某个节点的心跳，则认为该节点异常。这种机制在集群中各个节点之间网络正常的情况下运行良好，但是在发生网络分区（集群中各个节点网络通信异常）时会出现问题。比如 Server-Electer 节点收不到主节点的心跳，除了可能是因为主节点本身发生异常，还有可能是因为 Server-Electer 和主节点之间的网络通信发生异常。这时，如果 Server-Electer 和 Server-2、Server-3 之间的通信正常，则 Server-Electer 会从两个备节点中选出一个主节点，这里假定选举 Server-2 为主节点，则集群出现两个主节点，我们称之为双主问题。如果集群出现双主问题，则在 Server-1 的网络恢复后，备节点 Server-3 收到 Server-1 和 Server-2 两个主节点的数据同步请求，Server-3 的数据就会出现不一致的情况

出现双主问题时该如何处理呢？租约机制给了我们很好的解决方案。在租约机制的实现中，由选举节点向其他节点发送租约，如果该节点持有有效的租约，则认为该节点可以正常提供服务。例如三个工作节点 Server-1、Server-2、Server-3 仍然通过心跳机制向选举节点 Server-Electer 汇报自己的状态，选举节点在收到心跳后发送一个租约给三个工作节点，表示确认节点的状态，并允许在有效期内使用该租约的权力并对外提供服务

这时可以让选举节点 Server-Electer 给主节点 Server-1 一个特殊的租约，表示该节点为主节点，一旦发生网络分区或者其他问题，选举节点需要切换主节点，则只需等待之前主节点的租约到期，再重新给新选举出的主节点颁发新的租约即可。即使之前的主节点网络恢复，其他节点发现其租约已经到期，也不会将其认定为主节点

2. 分布式缓存

在分布式系统中，为了加快用户读取数据的速度，我们常常将经常被访问的数据缓存在客户端，这样在用户读取数据时，会先从本地缓存读取，如果在缓存中没有则从服务端获取最新的数据并更新本地缓存

但是这种方案存在缓存一致性问题，针对该问题有两种常见的解决方案，一种方案是轮询，即客户端在每次读取数据时，都先询问服务端缓存中的数据是不是最新的，如果不是，就从服务端获取最新的数据。采用这种方案时，每次读取数据都要与服务端通信，会增加服务端的压力，降低缓存的效果

另一种方案就是无效化，服务端对数据做修改时，会首先通知这些客户端数据已经失效，让客户端重新加载。这种做法的问题在于服务端需要维护所有客户端的状态，并且每次进行数据更新通知所有客户端。这增加了服务端的复杂度和运行的负担，如果联系不上客户端、则修改操作将无法顺利通知到客户端，使得客户端出现数据不一致的情况

那我们如何利用租约机制来解决缓存一致性问题呢？我们可以让服务器给缓存客户端发一个租约，在租约有效期内，客户从客户端读取数据，如果服务器要更改数据，则首先征求这块数据租约的客户端的同意，之后才可以修改数据。客户端在从服务器中取数据时获取租约，在租约有效期内，如果没有收到服务器的修改请求，就可以保证当前缓存中的内容是最新的。如果在租约时限内收到了数据修改请求，并且同意了，就需要清空缓存并重新加载缓存。在租约过期以后，客户端如果还要从缓存中读取数据，就必须获取新的租约，我们称这个过程为续约。

这样在租约期限内，客户端可以保证其缓存中的数据是最新的。同时，租约可以容忍网络分割问题，如果发生客户端崩溃或者网络中断，则服务器只需等待其租约过期就可以进行修改操作。如果服务器出错，丢失了所有客户端的信息，则它只需知道租约的最长期限，就可以在这个期限之后安全地修改数据。与无效化的方式相比，服务器只需记住还有租约的客户端即可。

3. 缓解主节点压力

在分布式系统中，元数据的信息都在主节点上维护，用户在访问数据时，首先需要在主节点上访问元数据的信息，来定位数据所在的数据节点，然后到数据节点上访问数据，这样所有客户端的请求都要先从主节点上获取源数据的信息，导致主节点压力过大

为了解决这个问题，我们可以将元数据的信息缓存在客户端，并通过租约机制保证租约有效期内主节点的数据和客户端一致。客户端在访问数据时，会先从本地缓仔中查找。如果本地援存没有，则再到主节点上查找，并更新缓存和租约信息，降低主节点的压力

租约机制的时钟同步问题

1. 颁发者的时钟比接收者的时钟快

如果颁发者的时钟比接收者的时钟快，那么在颁发者认为租约已经过期时，接收者却依旧认为租约有效，导致承诺失效，影响系统的正确性。通常做法是将颁发者的有效期限设置得比接收者的略大，只要大过时钟误差，就可以避免对租约有效性产生影响

2. 颁发者的时钟比接收者的时钟慢

如果颁发者的时钟比接收者的时钟慢，则当接收者认为租约已经过期时，颁发者依旧认为租约有效。接收者可以在租约到期前，以再次申请租约的方式解决这个问题

租约机制的应用

1. HDFS 中的租约机制

在 HDFS 中，当客户端用户向某个文件中写数据时，为了保障数据的一致性，其他客户端是不允许向此文件写数据的。那么 HDFS 是如何实现这一点的呢？答案是租约机制，当客户要写某一个 HDFS 文件时，首先从 HDFS 服务获取一个写该文件的租约，只有持有该租约的客户端才允许对该文件进行写操作，否则客户端对该文件的写请求将被驳回，客户端在对文件写操作完成时释放租约

2. Eureka 中的租约机制

Eureka 实现了服务注册和服务发现的功能。Eureka 的角色分为服务端（EurekaServer）和客户瑞，客户端指注册到注册中心（EurekaServer）的服务实例，又分为服务提供者和服务消费者，服务消费者从计册中心获取服务提供者的服务地址，并调用该服务。服务提供者在启动时，首先会将自己的信息注册到 EurekaServer，并维护一个续约请求，持续发送信息给 EurekaServer 表示其正常运行。如果 EurekaServer 长时间收不到续约请求，会将该服务实例从服务列表中剔除

租约机制的特性

1. 在租约机制的颁发过程中只要求网络可以单向通信，同一个租约颁发者可以重复向接受方发送租约，颁发者即使偶尔发送租约失败，也可以简单地通过重发租约来解决向题
2. 机器宕机对租约机制的影响不大，如果颁发者发生宕机，则宕机的颁发者通常无法改变之前的承诺，不会影响租约的正确性。在颁发者宕机恢复后，如果颁发者恢复了之前的租约信息，则颁发者可以继续遵守租约的承诺。如果颁发者无法恢复租约信息，则只需等待一个最大的租约超时时间即可
3. 租约机制依赖于有效期，这就要求颁发者和接收者的时钟同步
4. 在实际实现中，我们还需要考虑租约失效后颁发者或主节点资源释放的问题

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！