分布式系统原理Day04-Lease机制

你的名字 2023-03-02 05:05 18阅读 0赞

### Lease机制 ###

*  基于Lease协议的分布式Cache系统
 *  Lease机制的分析
 *  基于Lease机制确定节点状态
 *  Lease的有效期选择

# 基于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**的有效期时长
 *  实践中可以以此作为参考并综合选择合适的时长