远方的灯塔 - 专注于服务端技术分享 远方的灯塔 - 专注于服务端技术分享
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)

Terwer Green

一个后端老菜鸟
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)
  • JavaSE

  • 开源框架

  • Linux

  • Struts2

  • Hibernate

  • Webservice

  • 分布式

    • RPC架构设计及IO模型
    • NIO编程及其三大核心原理
    • NIO三大核心之缓冲区(Buffer)
    • NIO三大核心之通道(Channel)
    • NIO三大核心之选择器(Selector)
    • Netty核心原理
    • 线程模型以及传统IO阻塞模型
    • Reactor模型
    • Netty线程模型
    • Netty核心API介绍
    • Netty入门与异步模型
    • Netty高级进阶之Netty编解码器
    • Netty高级进阶之基于Netty的群聊天室案例
    • Netty高级进阶之基于Netty的HTTP服务器开发
    • Netty高级进阶之基于Netty的Websocket开发网页聊天室
    • Netty高级进阶之Netty中的粘包和拆包的解决方案
    • Nety源码剖析
    • 自定义RPC框架之分布式架构网络通信理论
    • 自定义RPC框架之基于Netty实现RPC框架
    • 分布式架构理论
    • 分布式理论之数据一致性
    • 分布式理论之CAP定理
    • 分布式理论之BASE定理
    • 分布式一致性协议之两阶段提交协议(2PC)
    • 分布式一致性协议之三阶段提交协议(3PC)
    • 分布式一致性协议之NWR协议
    • 分布式一致性协议之Gossip协议
    • 分布式一致性协议之Paxos协议
    • 分布式一致性协议之Raft协议
    • 分布式一致性协议之Lease机制
      • 分布式系统设计策略之心跳检测
      • 分布式系统设计策略之高可用
      • 分布式系统设计策略之容错性
      • 分布式系统设计策略之负载均衡
      • 分布式架构服务调用
      • 分布式服务治理之服务协调
      • 分布式服务治理之服务削峰
      • 分布式服务治理之服务降级
      • 分布式服务治理之服务限流
      • 分布式服务治理之服务熔断
      • 分布式服务治理之服务链路追踪
      • 架构设计基本原则之开闭原则(OCP)
      • 架构设计基本原则之单一职责原则(SRP)
      • 架构设计基本原则之接口隔离原则(ISP)
      • 架构设计基本原则之里式替换原则(LSP)
      • 架构设计基本原则之依赖倒置原则(DIP)
      • 架构设计基本原则知识扩展
      • 分布式架构知识拓展与总结
    • 分布式框架

    • 后端开发
    • 分布式
    terwer
    2022-05-04
    目录

    分布式一致性协议之Lease机制

    # Lease机制

    # 什么是Lease机制

    Lease机制,就是租约机制,是一种在分布式协议中常用的协议,是维护分布式系统中数据一致性的常用工具。

    Lease机制的特点:

    • Lease是颁发者对一段时间内数据一致性的承诺
    • 颁发者发出Lease后,不管是否被接受,只要Lease不过期,颁发者都会按照协议,遵守承诺
    • Lease的持有者只能在Lease的有效期内使用承诺,一旦Lease超时,持有者需要放弃执行,重新申请Lease。

    以租车为例:

    image-20220409144750794

    image-20220409144832400

    # Lease机制解决了什么问题

    分布式系统中,如何确定一个节点是否正常工作?

    假设有5个副本,1号是主副本。

    image-20220409145116580

    在分布式系统中最直观的办法是在主副本与副本之间维持一个心跳,期望通过心跳是否存在判断节点是否存活。

    心跳其实无法从根本上解决分布式下节点是否正常这个问题,例如如下场景:

    1. 在某个时候几点Node1发生网络抖动或者网络中断情况(不是宕机),导致节点无法接收心跳

      image-20220410204553743

    2. 会在剩下的节点中选区一个当做主节点

      image-20220410204709613

    主要解决思路有四种:

    • 设计能够容忍双主的协议
    • Raft协议-通过term版本高的同步低的
    • 用Lease机制
    • 涉及去中心化-Gossip协议

    # Lease的原理

    1. 引入中心节点负责下发Lease

      image-20220410210514165

    2. 出现网络问题

      image-20220410210719374

    在1.05如果出现网络抖动,会导致其他节点申请Lease失败,因为节点在1.10之前都会承认有主节点,不允许其他节点再申请Lease。

    1. 如果网络回复

      image-20220410211116169

    2. 如果到了1.10,主节点会进行续约操作,然后下发新的Lease

      image-20220410211339197

    3. 如果主节点宕机,其他节点申请Lease也会失败,承认主节点的存在

      image-20220410211536508

    4. 当Lease过期时,副节点申请Lease成功

      image-20220410211853713

    # Lease的容错

    1. 主节点宕机

      Lease机制可容忍网络、接收方差错,时间就是Lease剩余的过期时长。

    2. 中心节点异常

      颁发者宕机可能使得所有节点没有Lease,系统处于不可用状态。解决办法是使用一个小集群而不是单个节点来作为颁发者。

    3. 时差问题

      中心节点与主节点之间的时差可能存在问题,只需要中心节点考虑时钟误差即可。

    按照经验,Lease的时间差一般取1-10s即可。太短网络压力大,太长则,收回承诺时间过长,影响可用性。

    # 应用

    1. GFS(Google 文件系统)中,Master通过Lease决定哪个是主副本,Lease在给各个节点的心跳响应中携带。

      收不到心跳,则等待Lease过期,然后在颁发给其他节点。

    2. chubby中,paxos选主后,从节点会给主办法lease,在期限内,不允许选择其他节点为主。

      主节点给client发送lease,用于判断client是否存活。

    编辑 (opens new window)
    #rpc#lease
    上次更新: 2023/02/22, 13:47:25
    分布式一致性协议之Raft协议
    分布式系统设计策略之心跳检测

    ← 分布式一致性协议之Raft协议 分布式系统设计策略之心跳检测→

    最近更新
    01
    解决css部分border被圆角切掉之后圆角的边框消失问题
    03-18
    02
    使用TypeScript开发一个自定义的Node-js前端开发脚手架
    03-08
    03
    Github-Actions使用release-please实现自动发版
    03-06
    更多文章>
    Theme by Vdoing | Copyright © 2011-2023 Terwer Green | MIT License | 粤ICP备2022020721号-1 | 百度统计
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式