租约机制详解

概述

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

  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. 在实际实现中,我们还需要考虑租约失效后颁发者或主节点资源释放的问题