远方的灯塔 - 专注于服务端技术分享 远方的灯塔 - 专注于服务端技术分享
首页
  • 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
    目录

    分布式一致性协议之Raft协议

    # Raft协议

    # 什么是Raft协议

    Paxos论证了一致性协议的可行性,但是不好懂,缺少必要的细节,工程实现难度高。广为人知的实现目前只zk的zab协议。

    Paxos的出现为分布式的强一致性提供了很好的理论基础,但是paxos协议本身理解起来困难,实现复杂。

    斯坦福大学的RamCloud项目中提出了易理解、易实现的分布式一致性复制协议Raft。C++、Java和Go都有对应的实现,Raft相对简洁。

    引入主节点、通过竞选确认主节点。节点;类型:follower、candidate和leader。

    leader会周期性的发送心跳包给follower。每个follower设置一个随机的竞选超时时间,一般为150~300ms,如果在这个时间内没有收到心跳包,就会变成candidate。进入竞选阶段,通过竞选阶段投票人多的成为leader。

    image-20220406235432501

    # Raft相关概念

    1. 节点状态
      • Leader(主节点):接收client请求,写入本地后,同步到其他副本中
      • Follower(从节点):从Leader中接收更新请求,然后写入本地日志文件。对客户端提供读请求
      • Candidate(候选节点):如果Follower在一段时间内,没有接收到心跳,则判断Leader可能发生故障,发起主提议。节点状态从Follower变成Candidate状态,直到选主结束
    2. termId:任期号,时间被划分为一个个任期,每次选举后产生一个新的termId,一个任期内只能有一个leader。
    3. requestVote:请求投票,Candidate在选举过程中发起,收到多数派响应后成为leader。

    # 竞选阶段流程

    http://thesecretlivesofdata.com/raft/

    https://raft.github.io/

    单节点不存在数据一致性问题,一个节点容易达成一致性。

    多个节点达成一致性

    不同的状态

    image-20220407231520954

    竞选流程

    20220407-231357

    1. 最初阶段,只有Folllower,没有leader

      image-20220407231758641

      FollowerA等待随机竞选超时之后,没收到leader发来的心跳包,进入竞选阶段。

      image-20220407232139502

    2. 此时A发送投票请求给其他节点

      image-20220407232653872

    3. 其他节点会对请求进行回复,如果超过一般节点进行了回复,那么该节点就会由candidate变成leader

      image-20220407232903317

    4. 之后leader会周期性的给follower发送心跳包,follower接收到心跳包,会重新开始计时

      image-20220407233135008

    # leader节点宕机

    image-20220407233525012

    image-20220407233608165

    image-20220407233724576

    image-20220407233814755

    # 多个Candidate竞选

    1. 如果有多个follower成为candidate,并且获得的票数相同,那么就需要重新进行投票。

    image-20220407233952703

    1. 当重新开始投票时,由于每个节点设置的随机竞选超时时间不同,因此再次出现多个candidate进行竞选并且获得相同票数的概率很低。

      image-20220407234630560

      image-20220407234745473

    # 日志复制

    1. 来自客户端的修改都会传到leader。该修改还未提交,只是存在日志中

      image-20220407235012230

    2. leader把修改复制到所有follower

      image-20220407235217320

    3. leader会等待大多数follower都进行了修改,然后才将修改提交。

      image-20220408195907817

    4. leader通知所有follower,让他们进行修改,此时所有节点达成一致。

      image-20220408200024511

    5. 多次日志复制的情况

      image-20220408200143060

    image-20220408200359398

    image-20220408200441706

    # 网络分区

    面对网络分区,Raft也可以保持一致。

    1. 初始状态下,B节点对其他节点发送心跳

      image-20220408231418452

    2. 当网络分区,出现网络分区的请求后,只能对A发送心跳,同时其他节点会再选出一个leader

      image-20220408231720682

    # 网络分区情况的日志复制

    网络分区数据复制也可以完成数据一致性

    1. 不同分区写入数据不同

      image-20220409010415632

    2. 最终E节点termid最大,成为leader节点,同步节点数据,达成数据一致性

      image-20220409143241157

    编辑 (opens new window)
    #rpc#raft
    上次更新: 2023/02/22, 13:47:25
    分布式一致性协议之Paxos协议
    分布式一致性协议之Lease机制

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

    最近更新
    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 | 百度统计
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式