基于Lease协议的分布式Cache系统

• 问题背景:
  • 在一个分布式系统中,有一个中心服务器节点,中心服务器存储,维护着一些数据,这些数据是系统的元数据
  • 系统中其余的节点通过访问中心服务器节点读取,修改上面的元数据
  • 由于系统中的各种操作都依赖于元数据,如果每次读取元数据的操作都访问中心服务器节点,那么中心服务器节点的性能就会成为系统的瓶颈
    • 所以,需要设计一种元数据cache, 在各个节点上cache元数据信息,从而减少对中心服务器节点的访问,提高性能
    • 系统的正确运行依赖于元数据的正确,这就要求各个节点上cache的数据始终与中心服务器上的数据一致 ,cache中不能是旧的脏数据
    • 设计的cache系统要能最大可能的处理节点宕机,网络中断等异常,最大程度提高系统的可用性
• 为了解决以上问题,利用Lease机制实现基于Lease协议的分布式Cache系统
• 基于Lease协议的分布式Cache系统的基本原理:
  • 中心服务器在向各节点发送数据时同时向节点发送一个lease
  • 每个lease具有一个有效期,通常是一个明确的时间节点,一旦真实时间超过这个时间点,则lease过期失效
  • lease的有效期与节点收到lease的时间无关,节点可能收到lease时该lease就已经过期失效
  • 假设中心服务器与各节点的时钟是同步的,中心服务器发出的lease的含义为:
    • 在lease的有效期内,中心服务器保证不会修改对应数据的值
    • 这样,节点收到数据和lease后,将数据加入本地cache. 一旦对应的lease超时,节点将对应的本地cache删除
    • 中心服务器在修改数据时,首先阻塞所有新的读请求,并等待之前为该数据发出的所有lease超时过期,然后修改数据的值
• 基于lease的cache中,客户端节点读取元数据的流程:
  • 判断元数据是否已经处于本地cache且lease处于有效期内:
    • 是: 直接返回cache中的元数据
    • 否: 向中心服务器节点请求读取元数据信息:
      • 服务器接收到读取请求后,返回元数据及一个对应的lease
      • 客户端是否成功接收到服务器返回的数据:
        • 失败或者超时: 退出流程,读取失败,可以重试
        • 成功: 将元数据与该元数据的lease记录到内存中,返回元数据
• 基于lease的cache中,客户端节点修改元数据的流程:
  • 节点向服务器发起修改元数据请求
  • 服务器接收到修改请求后,阻塞所有新的读数据的请求,即接收读请求,但是不返回数据
  • 服务器等待所有与该元数据相关的lease超时
  • 服务器修改元数据并向客户端节点返回修改成功
• 基于lease的cache机制可以保证各个节点上的cache数据与中心服务器上的数据始终一致:
  • 中心服务器在发送数据的同时设置了节点对应的lease
  • 在lease有效期内,服务器不会修改数据,从而客户端节点可以在lease有效期内cache数据
• 基于lease机制的cache能够容错的关键:
  • 服务器一旦发出数据以及cache, 无论客户端是否收到,无论后续客户端是否宕机,无论后续网络是否正常,服务器只要等待lease超时,就可以保证对应的客户端不会再继续cache数据,才可以进行修改数据而不会破坏cache的一致性
• 基于lease机制的cache的优化改进:
  • 服务器在修改元数据时首先要阻塞所有新的请求,保证没有读服务
  • 这是为了防止发出新的lease从而引起不断有新客户端节点持有lease并缓存着数据,形成“活锁”
  • 优化方法:
    • 服务器在进入修改数据流程后,一旦收到读请求则只返回数据但不设置lease
    • 这样在修改流程执行的过程中,客户端可以读到元数据,只是不能缓存元数据
    • 进一步优化:
      • 当进入修改流程,服务器设置的lease的有效期期限选择为已发出的lease的最大有效期
      • 这样,客户端可以继续在服务器进入修改流程后继续缓存元数据,但是服务器等待所有lease过期的时间不会因为设置新的lease而不断延长
• Cache机制与多副本机制的异同:
  • 相同点: 都是将一份数据保存在多个节点上
  • 不同点:
    • cache机制简单,可以随时删除丢弃,并且命中已删除cache的后果仅仅是需要访问数据源读取数据
    • 副本不能随意丢弃,每失去一个副本,服务的质量都在下降,一旦副本下降到一定程度,则服务往往不再可用

Lease机制的分析

• Lease的定义:
  • Lease是发送方设置的在某一有效期内的承诺
  • 发送方一旦发出lease, 则无论接收方是否收到,也无论后续接收方处于何种状态,只要lease不过期,发送方一定严守承诺
  • 接收方在lease的有效期内可以使用发送方的承诺,一旦lease过期,接收方一定不能继续使用发送方的承诺
• Lease机制具有很高的容错能力:
  • 通过引入有效期 ,Lease机制能否非常好的容错网络异常
  • Lease的发送过程只依赖于网络可以单向通信,即使接收方无法向发送方发送消息,也不会影响Lease的发送
  • 由于Lease的有效期是一个确定的时间点 ,Lease的语义和发送Lease的具体时间无关,所以同一个Lease可以被发送方不断重复向接收方发送
  • 即使发送方偶尔发送Lease失败,发送方也可以简单的通过重发的方法解决
  • 一旦Lease被接收方成功接收,后续Lease机制不再依赖于网络通信,即使网络完全中断 ,Lease机制也不会受到影响
• Lease机制能较好地容错节点宕机:
  • 如果发送方宕机,则宕机的发送方通常无法改变之间的承诺,不会影响Lease的正确性
    • 在发送方恢复后,如果发送方恢复了之前的Lease信息,发送方可以继续遵守Lease的承诺
    • 如果发送方无法恢复Lease信息,则只需等待一个最大的Lease超时时间就可以使得所有的Lease都失效,从而不破坏Lease机制
  • 如果接收方宕机,发送者不需要做更多的容错处理,只需要等待Lease过期失效,就可以收回承诺,在工程实践中就是收回之前赋予的权限,身份等
• Lease机制不依赖于存储:
  • 发送方可以持久化发送过的Lease信息,从而在宕机恢复后可以使得在有效期的Lease继续有效
  • 这只是一个Lease机制的优化,即使发送方没有持久化Lease信息,也可以通过等待一个最大的Lease时间的方式使得之前所有发送的Lease失效,从而保证机制持续有效
• Lease机制依赖于有效期:
  • 要求发送方和接收方的时钟是同步的
    • 如果发送方的时钟比接收方慢:
      • 当接收方认为Lease已经过期的时候,发送方依旧认为Lease有效
      • 接收方可以用在Lease到期前申请新的Lease的方式解决这个问题
    • 如果发送方的时钟比接收方快:
      • 当发送方认为Lease已经过期的时候,接收方依旧认为Lease有效
      • 发送方可能将Lease发送给其余节点,造成承诺失效,影响系统的正确性
      • 实践中的通常做法是将发送方的有效期设置设置得比接收方的略大,只需大过时钟误差就可以避免对Lease的有效性的影响

基于Lease机制确定节点状态

• 分布式协议依赖于对节点状态认知的全局一致性:
  • 一旦节点Q认为某个节点A异常,则节点A也必须认为自己异常,从而节点A停止作为primary节点,避免 “双主” 的问题出现
• 解决 “双主” 的问题有两种思路:
  • 放弃使用中心化设计,改用去中心化设计: 设计的分布式协议可以容忍 “双主” 错误,不依赖于对节点状态的全局一致性认识或者全局一致性是全体协商后的结果
  • 利用Lease机制
• 利用Lease机制确定节点状态:
  • 由中心节点向其余节点发送Lease, 如果某个节点持有有效的Lease, 则认为该节点正常可以提供服务
  • 示例:
    • 节点A,B,C周期性的发送heart beat报告自身状态
    • 节点Q收到heart beat后发送一个Lease, 表示节点Q确认了节点A,B,C的状态,并允许节点在Lease有效期内正常工作
    • 节点Q可以给primary节点一个特殊的Lease, 表示该节点可以作为primary工作
    • 一旦节点Q希望切换新的primary, 只需要等待前一个primary的Lease过期,就可以安全的发送新的Lease给新的primary节点,而不会出现 “双主” 问题
• 在工程实践中,如果只使用一个中心节点发送Lease存在很大的风险:
  • 如果该中心节点宕机或者网络异常,则所有的节点没有Lease. 从而造成系统高度不可用
  • 实际系统中总是使用多个中心节点互为副本, 成为一个小的集群,该小集群具有高可用性,对外提供发送Lease的功能
  • chubby和zookeeper都是基于使用多个中心节点互为副本的设计

Lease的有效期选择

• 在工程实践中,通常使用10秒级别作为Lease的有效期时长
• 实践中可以以此作为参考并综合选择合适的时长