浅谈 Raft 分布式一致性协议|图解 Raft

前言

大家好,这里是白泽。本文是一年多前参加字节训练营针对 Raft 自我整理的笔记。

本篇文章将模拟一个KV数据读写服务,从提供单一节点读写服务,到结合分布式一致性协议(Raft)后,逐步扩展为一个分布式的,满足一致性读写需求的读写服务的过程。

其中将配合引入Raft协议的种种概念:选主、一致性、共识、安全等,通篇阅读之后,将帮助你深刻理解什么是分布式一致性协议。

一、 单机KV数据读写服务

image-20220818164835626

DB Engine这里可以简单看成对数据的状态进行存储(比如B+树型的组织形式),负责存储KV的内容 ,并假设这个KV服务将提供如下接口:

  • Get(key) —> value
  • Put([key, value])

思考此时KV服务的可靠性:

  • 容错:单个数据存储节点,不具备容错能力。
  • 高可用:服务部署在单节点上,节点宕机将无法提供服务。

思考此时KV服务的正确性:

  • 单进程,所有操作顺序执行,可以保证已经存储的数据是正确的

数据规模不断增加,我们需要扩大这个KV服务的规模,将其构建成一个分布式的系统

二、一致性与共识算法

2.1 从复制开始

既然一个节点会挂,那么我们就多准备一个节点!

image-20220818170355643

我们这里只考虑主副本负责接收数据,而从副本只负责同步接收主副本数据的模式,如果主从都开放数据接收能力,将要考虑更多高可用和数据一致性的问题。

2.2 如何复制

image-20220818170959372

  • 主副本定期拷贝全量数据到从副本(代价太高)
  • 主副本拷贝操作日志到从副本:如果你了解MySQL的主从同步,你就会想起它也是通过从副本监听主副本当中的bin log操作日志变化,进行集群数据同步的,因此这种方式也是更主流的选择。

2.3 具体的写流程

image-20220818171626880

  • 主副本把所有的操作打包成Log

    • 所有的Log写入都是持久化的,保存在磁盘上
  • 应用包装成状态机(也就是DB Engine部分),只接收Log作为Input

  • 主副本确认Log已经成功写入到从副本机器上,当状态机apply后,返回客户端(关于写入之后,请求返回客户端的时机,是可以由应用控制的,可以是Log写入从副本之后,就从主副本机器返回,也可以等Log完成落盘之后,再返回)

2.4 具体的读流程

image-20220818172742667

  • 方案一:直接读状态机(这里指的是DB),要求上一步写操作进入状态机后再返回client(数据已落盘)
  • 方案二:写操作复制Log完成后直接返回,读操作Block等待所有pending log进入状态机
  • 如果不遵循上述两种方案:可能存在刚刚写入的值读不到的情况(在Log中)

2.5 什么是一致性

对于我们的KV服务,要像操作一台机器一样,对用户来说在写入成功后,就应该能读到最近写入的值,而不关心具体底层是如何分布式实现。

一致性是一种模型(或语义),约定一个分布式系统如何向外界提供服务,KV服务中常见的一致性模型有以下两种:

  • 最终一致性:读取可能暂时读不到但是总会读到
  • 线性一致性:最严格,线性时间执行(写完KV确保就能读到),是最理想中的状态

2.6 复制协议-当失效发生

上述用到的添加了一个从副本节点的方式,我们暂且将其称为山寨版分布式一致性协议——复制协议(因为它依赖于主从副本间的复制操作)

那么当主副本失效时,以这个复制协议为基础的KV服务的运行情况如何呢:

  • 容错能力:没有容错能力,因为主副本停了,KV服务就停了
  • 高可用:或许有,取决于我们发现主副本宕机后多快将从副本切换为主副本(手动切换)
  • 正确性:正确,因为操作只从一台机器发起,可以控制所有操作返回前都已经复制到另一台机器了

衍生出的一些的问题:

  • 如何保证主副本是真的失效了,切换的过程中如果主副本又开始接收client请求,则会出现Log覆盖写的情况
  • 如果增加到3个乃至更多的节点,每次PUT数据的请求都等待其他节点操作落盘性能较差
  • 能否允许少数节点挂了的情况下,仍然可以保持服务能工作(具备容错能力)

2.7 共识算法

什么是共识:一个值一旦确定,所有人都认同

共识协议不等于一致性:

  • 应用层面不同的一致性,都可以用共识算法来实现

    • 比如可以故意返回旧的值(共识算法只是一个彼此的约定,只要数据存储与获取符合需求,达成共识即可
  • 简单的复制协议也可以提供线性一致性(虽然不容错)

一般讨论共识协议时提到的一致性,都指线性一致性

  • 因为弱一致性往往可以使用相对简单的复制算法实现

三、一致性协议案例:Raft

3.1 Ratf概述

image-20220818195752968

  • 2014年发表

  • 易于理解作为算法设计的目标

    • 使用了RSM、Log、RPC的概念
    • 直接使用RPC对算法进行了描述
    • Strong Leader-based(所有操作都是Leader发起的)
    • 使用了随机的方法减少约束(比如选主时Follower谁先发现Leader失联就发起选主)

3.2 复制状态机(RSM)

image-20220818200110493

  • RSM(replicated state machine)

    • Raft中所有的共识机制(consensus)都是直接使用Log作为载体:简单说就是client将Log提供给Raft(也就是上图的Consensus Module),Raft确定这个Log已经Commit之后(写入Log文件),将Log提供给用户的状态机
    • 注意此时状态机是一个内存中的存储概念,当然后续每个节点数据还涉及到落盘持久化,这是具体应用层面的问题了,这里讨论的更多是Raft协议的原理概念,使用状态机对此进行抽象
  • Commited Index(这里先有个概念,用于标识Log中哪些数据可以提交给状态机

    • 一旦Raft更新Commited Index,意味着这个Index前所有的Log都可以提交给状态机了
    • Commited Index是不持久化的,状态机也是volatile的(断电清空),重启后从第一条Log开始恢复状态机,Raft协议工作过程中每个节点的Commited Index可能是不一致的,但是Ratf可以保证最终所有节点都是一致的

3.3 Raft角色

image-20220818203522816

  • Leader是所有操作的发起者,会把Log同步给Follower,确定哪个Log已经Commit了
  • 接受Leader的请求,并且在发现Leader消失,则转换为Candidate,向其他Follower申请投票,如果获得票数过半,则晋升为Leader

3.4 Raft日志复制

image-20220818204052036

接下来讲解一下Raft协议中Log是如何在节点间同步的:

  1. 第一张图s2是当前Leader,紫色的小箭头指向每个节点已经确认commit的Log位置
  2. 第二张图s2又append了一条新的Log,用K标识
  3. 第三张图表示,s2将自己收到的K以及自己的Commited Index发送给所有Follower节点。Follower都同步Leader的Log以及Commited Index,并且Follower的状态机检测到自己的Commited Index又向前推进了,说明有新的Log值达成了共识,就会把Commited Index没读取的Log值应用给状态机
  4. 第四张图,当Follower完成步骤三的操作之后,会告诉Leader自己已经拿到这个Log值了,Leader在收到多数派的确认消息后,就可以确定这个K已经永远的持久化,也就是已经Commit了,因此将Commited Index向后推一位

这里有一个细节就是,虽然Raft协议使节点间的数据最终达成了一致,但是节点Log数据落盘时间是有先后的(因为Commited Index在各节点之间存在差异,所以Log与状态机是有时差的)

3.5 Raft从节点失效

image-20220818210451385

  1. 图一假设s3失效了很久,Log有很多数据没有同步
  2. 图二表示此时的Leader是s2,将自己Log中的K和自己的Commited Index复制给s1
  3. 图三中s2的K完成了commit(流程参考Raft日志复制),因为s1、s2共两个节点已经形成了多数派(此时已经有容错能力了)
  4. 图四中,s3尝试重新同步数据,在Raft协议中,s3会向s2逆向迭代的去获取Log数据(K、QK、TQK、XTQK),直到与s3当前Log相对齐则完成数据同步(当然Raft具体实现中应用对此过程进行了优化)

3.6 Raft Term

image-20220818211507017

Term(周期的概念),在Raft中相当于一个逻辑的时钟,下面介绍:

  • 每个Leader服务于一个term:一旦发现更高的term,那么表示我已经不是Leader了
  • 每个term至多只有一个leader:选出新的Leader,会使得term增加
  • 每个节点存储当前的term
  • 每个节点term从一开始,只增不减
  • 所有的rpc的request response 都携带term
  • 只commit本term内的log

3.7 Raft主节点失效

  • Leader定期发送AppendEntries RPCs 给其余所有的节点

  • 如果Follower 有一段时间没有收到Leader的AppendEntries,则转换身份为Candidate

  • Candidate自增自己的term,同时使用RequestVote PRCs 向剩余节点请求投票

    • raft在检查是否可以投票时,会检查log是否outdated,至少不比本身旧才会投票给对应的Candidate
  • 如果多数派投给它,则成为该term的leader

3.8 Raft Leader failure

image-20220818213612004

接下来模拟一下主节点失效后的流程,并且注意此时图一当中,s1的Log内容比较特殊,为XW,这个场景是可以实现的,比如一开始有s1、s2、s3,其中s1是Leader,首先将X同步给了s2和s3,并且接受到了新的W,但是突然s1节点卡死了,s2和s3重新开始选举Leader为s2,最终s2和s3的Log变成了XTQ(这只是一种情况,一切皆有可能),然后s1又恢复了。

关于为什么s3落后s2两条Commited Index,有可能是s2一次同步了两条Log给s3,而s3的状态机还没来得及同步数据,但是s3接收到在标识TQ的Log后,将其commit到自己的Log之中,就返回确认响应给了s2,s2将自己的Commited Index向后推进到Q的位置。

  • 从图二开始,s3发现s2挂了,没有Leader,则将自己的term+1变为3,并且向s1请求Vote
  • 图三中,s1发现RequestVote是来自term等于3的,大于自己的term,因此将自己的term也更新为3,同时答应给s3投票,达成多数派条件,s3成为新的Leader
  • 图四,s3开始同步自己的Log给s1,但是发现s1中的Log起初为XW,而s3中为XTQY,因此还是会按照从后往前迭代的方式将数据同步给s1(Y、QY、TQY、XTQY),最后s1虽然与同步状态发生了冲突,但是由于Raft是Strong Leader-based的,会完全按照Leader的内容覆盖自己的Log

3.9 Raft 安全性 - 同 Term

  • 对于Term内的安全性

    • 目标:对于所有已经commited的<term, index>位置上至多只有一条log
  • 由于Raft的多数派选举,我们可以保证在一个term中只有一个leader

    • 我们可以证明一条更严格的声明:在任何<term, index>位置上,至多只有一条log

3.10 Raft 安全性 - 跨 Term

  • 对于跨Term的安全性

    • 目标:如果一个log被标记commited,那这个log一定会在未来所有的leader中出现
  • 可以证明这个property:

    • Raft选举时会检查Log是否outdated,只有最新的才能当选Leader
    • 选举需要多数派投票,而commited log也已经在多数派当中(必有overlap)
    • 新Leader一定持有commited log,且Leader永远不会overwrite log

四、回到KV

4.1 重新打造KV服务

结合Raft算法,更新一下我们的KV

image-20220818220326290

回顾一下一致性读写的定义:

  • 方案一:

    • 写log被commit了,返回客户端成功
    • 读操作也写入一条log(因为读的数据可能还没从Log写入状态机,无法读取状态机数据),状态机apply log后返回client
    • 增加Log量
  • 方案二:

    • 写log被commit了,返回客户端成功
    • 读操作先等待所有commited log apply,再读取状态机
    • 优化写时延
  • 方案三:

    • 写log被状态机apply,返回给client
    • 读操作直接读状态机
    • 优化读时延

多个副本只有单个副本可以提供服务(一个Leader万一忙不过来怎么办)

  • 服务无法水平扩展

  • 增加更多Raft组(不多展开)

    • 如果操作跨Raft组(对key进行分组,每一个Raft负责读写一个range的key)

image-20220818221735160

4.2 回到共识算法

  • Raft:关于log

    • 论文中就给出的方案,当过多的Log产生后,启动snapshot,替换掉Log
    • 如果对于持久化的状态机,如何快速的产生Snapshot(略)
    • 多组Raft的应用中,Log如何合流(略)
  • 关于configuration change(节点规模变化)

    • 论文中就给出的joint-consensus以及单一节点变更两种方案(很复杂,略)

image-20220818222211742

4.3 共识算法的未来

  • Raft Paxos相互移植

    • Raft有很多成熟的实现

    • 研究主要关注在Paxos上

    • 如何关联两种算法:

      • On the Parallels between Paxos and Raft, and how to Port Optimizations[1]
      • Paxos vs Raft: Have we reached consensus on distributed consensus?[2]

感兴趣可以关注公众号 「白泽talk」,白泽目前也打算打造一个氛围良好的行业交流群,文章的更新也会提前预告,欢迎加入:622383022。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/622519.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Android基于Matrix绘制PaintDrawable设置BitmapShader,以手指触点为中心显示原图像圆图,Kotlin(3)

Android基于Matrix绘制PaintDrawable设置BitmapShader&#xff0c;以手指触点为中心显示原图像圆图&#xff0c;Kotlin&#xff08;3&#xff09; 在 Android基于Matrix绘制PaintDrawable设置BitmapShader&#xff0c;以手指触点为中心显示原图像圆图&#xff0c;Kotlin&#…

读写分离的手段——主从复制,解决读流量大大高于写流量的问题

应用场景 假设说有这么一种业务场景&#xff0c;读流量显著高于写流量&#xff0c;你要怎么优化呢。因为写是要加锁的&#xff0c;可能就会阻塞你读请求。而且其实读多写少的场景还很多见&#xff0c;比如电商平台&#xff0c;用户浏览n多个商品才会买一个。 大部分人的思路可…

List集合遍历过程中修改元素(有坑)

说来惭愧&#xff0c;学 java 2年了&#xff0c;对 “Java是值传递” 这句话还没有理解它的精髓&#xff0c;以至于编程的时候出现了一些错误&#xff0c;这里记录一下。 一.问题再现 1.1将List集合中的每个字符串更改为其他值 1.2将List集合中的对象更改为其他对象 二.问题分…

extern static 在linux 和 qt下差别

从五个点来说 1.p3.h 中 静态定义一个const的int 变量并且赋值 2.p5.h 声明函数test2的定义 3. 直接extern 引用声明 test1() 函数 而不是像p5.h一样 把函数声明写到头文件 在别的.c文件直接包含头文件 第二点和第三点 是引用声明函数的两种用法 4.main函数 中static静态定…

修改Echarts图表的标题和副标题的内容

直接上代码 var graphicConfig [ { type: "text", left: "center", top: "center", style: { text: "包日", // 初始化为空字符串 textAlign: "center", fill: "#000", fontSize: 14, fontWeight: "bold&qu…

光猫(无限路由器)插入可移动硬盘搭建简易版的NAS

1.场景分析 最近查询到了许多有关NAS的资料&#xff0c;用来替代百度云盘等确实有很多优势&#xff0c;尤其是具有不限速&#xff08;速度看自己配置&#xff09;、私密性好、一次投入后续只需要电费即可等优势。鉴于手上没有可以用的资源-cpu、机箱、内存等&#xff0c;查询到…

计算机找不到msvcp120.dll如何解决?总结五个可靠的教程

在计算机使用过程中&#xff0c;遇到“找不到msvcp120.dll”这一问题常常令人困扰。msvcp120.dll作为Windows系统中至关重要的动态链接库文件&#xff0c;对于许多应用程序的正常运行起着不可或缺的作用。那么&#xff0c;究竟是什么原因导致找不到msvcp120.dll呢&#xff1f;又…

【设计模式】什么场景可以考虑使用简单工厂模式

1.概述 工厂模式是一种创建型模式&#xff0c;主要作用就是创建对象&#xff0c;将对象的创建过程和使用的过程进行解耦。我们平时说的工厂模式实际上是对三种不同类型的工厂模式的统称&#xff0c;简单工厂、工厂方法、抽象工厂&#xff0c;而在23种设计模式中&#xff0c;只…

深度学习笔记(六)——网络优化(2):参数更新优化器SGD、SGDM、AdaGrad、RMSProp、Adam

文中程序以Tensorflow-2.6.0为例 部分概念包含笔者个人理解&#xff0c;如有遗漏或错误&#xff0c;欢迎评论或私信指正。 截图和程序部分引用自北京大学机器学习公开课 在前面的博文中已经学习了构建神经网络的基础需求&#xff0c;搭建了一个简单的双层网络结构来实现数据的分…

机器学习~从入门到精通(三)梯度下降法

一、梯度下降法 # 梯度下降不是一种算法&#xff0c;是一种最优化方法 # 上节课讲解的梯度下降的案例 是一个简单的一元二次方程 # 最简单的线性回归&#xff1a;只有一个特征的线性回归&#xff0c;有两个theta # 二、在多元线性回归中使用梯度下降求解 三、### R…

求斐波那契数列矩阵乘法的方法

斐波那契数列 先来简单介绍一下斐波那契数列&#xff1a; 斐波那契数列是指这样一个数列&#xff1a;1&#xff0c;1&#xff0c;2&#xff0c;3&#xff0c;5&#xff0c;8&#xff0c;13&#xff0c;21&#xff0c;34&#xff0c;55&#xff0c;89……这个数列从第3项开始 &…

行业内参~移动广告行业大盘趋势-2023年12月

前言 2024年&#xff0c;移动广告的钱越来越难赚了。市场竞争激烈到前所未有的程度&#xff0c;小型企业和独立开发者在巨头的阴影下苦苦挣扎。随着广告成本的上升和点击率的下降&#xff0c;许多原本依赖广告收入的创业者和自由职业者开始感受到前所未有的压力。 &#x1f3…

使用pygame实现简单的烟花效果

import pygame import sys import random import math# 初始化 Pygame pygame.init()# 设置窗口大小 width, height 800, 600 screen pygame.display.set_mode((width, height)) pygame.display.set_caption("Fireworks Explosion")# 定义颜色 black (0, 0, 0) wh…

基于Java SSM框架实现在线作业管理系统项目【项目源码】计算机毕业设计

基于java的SSM框架实现在线作业管理系统演示 JSP技术 JSP技术本身是一种脚本语言&#xff0c;但它的功能是十分强大的&#xff0c;因为它可以使用所有的JAVA类。当它与JavaBeans 类进行结合时&#xff0c;它可以使显示逻辑和内容分开&#xff0c;这就极大的方便了运动员的需求…

IPv6组播--SSM Mapping

概念 SSM(Source-Specific Multicast)称为指定源组播,要求路由器能了解成员主机加入组播组时所指定的组播源。 如果成员主机上运行MLDv2,可以在MLDv2报告报文中直接指定组播源地址。但是某些情况下,成员主机只能运行MLDv1,为了使其也能够使用SSM服务,组播路由器上需要提…

k8s-数据卷

存储卷----数据卷 容器内的目录和宿主机的目录进行挂载 容器在系统上的生命周期是短暂的&#xff0c;delete&#xff0c;k8s用控制创建的pod&#xff0c;delete相当于重启&#xff0c;容器的状态也会恢复到初识状态 一旦容器回到初始状态&#xff0c;所有得分后天编辑的文件…

粒子群算法优化RBF神经网络回归分析

目录 完整代码和数据下载链接:粒子群算法优化RBF神经网络回归分析(代码完整,数据齐全)资源-CSDN文库 https://download.csdn.net/download/abc991835105/88738570 RBF的详细原理 RBF的定义 RBF理论 易错及常见问题 RBF应用实例,基于rbf的空调功率预测 代码 结果分析 展望…

通过Wireshark抓包分析谈谈DNS域名解析的那些事儿

原创/朱季谦 本文主要想通过动手实际分析一下是如何通过DNS服务器来解析域名获取对应IP地址的&#xff0c;毕竟&#xff0c;纸上得来终觉浅&#xff0c;绝知此事要躬行。 一、域名与IP地址 当在浏览器上敲下“www.baidu.com”时&#xff0c;一键回车&#xff0c;很快&#x…

Linux远程登陆协议ssh

目录 一、SSH服务 1. ssh基础 2. 原理 3. 服务端配置 3.1 常用配置项 3.2 具体操作 3.2.1 修改默认端口号 3.2.2 禁止root用户登录 3.2.3 白名单列表 3.2.4 黑名单列表 3.2.5 使用秘钥对及免交互验证登录 3.2.6 免交互式登录 一、SSH服务 1. ssh基础 SSH&…

VQE音频处理流程

VQE 上行VQE&#xff0c;主要针对MIC采集部分的音频增强 下行VQE&#xff0c;主要针对SPK播放部分的音频增强 附关键词解释 RES RES 模块为重采样&#xff08;Resampler&#xff09;模块。当AI上行或AO下行通路中开启VQE 各功能 模块时&#xff0c;在处理前后各存在一次重采样…