Raft 论文阅读笔记

最新推荐文章于 2024-07-02 21:25:27 发布
最新推荐文章于 2024-07-02 21:25:27 发布
阅读量694 收藏 3
点赞数 2
分类专栏： 分布式系统
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/rsy56640/article/details/89116768
版权

In Search of an Understandable Consensus Algorithm (Extended Version) 阅读笔记

首发于：https://github.com/rsy56640/paper-reading/tree/master/分布式/raft

Replicated State Machine

replicate log 来达成确定性状态机

在这里插入图片描述

共识算法需要保证 replicated log 一致性。

Paxos的问题

难以理解，难以实现。
Paxos 让每个 instance 独立，所以还需要合并成 sequential log；应该围绕 log 来设计整个系统。

Raft

只要看懂两个基本就能懂了：

  1. 全局维护的协议（Figure 3）
  2. 执行流程（Figure 2）

对系统的要求：broadcastTime ≪ electionTimeout ≪ MTBF（结点平均 crash 时间）

全局维护的协议

  • Election Safety：每个 term 最多只有一个 leader
  • Leader Append-Only：leader 绝不 覆盖 或 删除 自己的 log
  • Log Matching：如果2个 log 拥有相同的 term 和 index，那么 <= index 的所有 log entry 相同
  • Leader Completeness：leader 拥有 commit 过的所有 log
  • State Machine Safety：如果某个结点 apply 了 index 的 log，那么其他节点如果在这个 index 的 log 不一样，则不能 apply（这条感觉没啥用，毕竟 apply 之前都 commit 过了）

在这里插入图片描述

Raft 基础

每一个 server 有三种 member 状态：follower, leader, candidate。

在这里插入图片描述

每一个 term 最多只有一个 leader。term 通常由 election 和 normal operation 两个阶段组成。

在这里插入图片描述

每个 server 的 state

  • 被持久化在 server 上的数据
    • currentTerm：见到的最大的 term
    • votedFor：在这个 currentTerm 给谁 vote（没有就是 null）
    • log[]：log entries
  • 在 server 内存中的数据
    • commitIndex：commit 的最大的 log 的 index
    • lastApplied：apply 到 state machine 的最大的 log 的 index
  • 在 leader 内存中的数据（每次 election 后初始化）
    • nextIndex[]：nextIndex[i] 表示发送给 server[i] 的下一个 log index
    • matchIndex[]：matchIndex[i] 表示同步到 server[i] 的最大 index

Server 执行

  • 所有 server
    • 如果 commitIndex > lastApplied，apply log 到 state machine
    • 如果发现 term T > currentTerm，就设置 currentTerm = T，变为 Follower
  • Follower
    • 回复 Candidate 和 Leader 的 RPC
    • 如果超时，没有 Leader 的 Append-Log RPC 或者 Candidate 的 Vote RPC，就变为 Candidate
  • Candidate
    • 变为 Candidate 时，开启 election
      • currentTerm++
      • vote 自己
      • 重设 election timer
      • RequestVote RPC 发向其他 server
    • 如果获得 majority votes，就变为 Leader
    • 如果收到 Append-Log RPC，并且 term >= currentTerm，就变为 Follower
    • 如果超时，开启新的 election
  • Leader
    • election 成功后，发送 空Append-Log RPC（heartbeat），防止超时
    • 收到 client 的请求，append local log。回头 apply 到 state machine 后向 client 回复
    • 如果 log index > nextIndex[i]，就向 server[i] 发送 Append-Log RPC，发送 log 从 nextIndex[i] 开始
      • 如果成功，更新 nextIndex[i]
      • 如果因为 log inconsistent 失败，nextIndex[i]– 并 retry
    • 如果存在一个 N 使得 (1) N >commitIndex，(2) majority matchIndex[i] >= N，并且 (3) log[N].term == currentTerm，就设置 commitIndex = N

Vote 规则

  • 参数
    • term
    • candidateId
    • lastLogIndex
    • lastLogTerm
  • 返回值
    • term：currentTerm ，Candidate 落后，让其更新自己
    • voteGranted：bool 值，表明是否 vote
  • vote 规则
    • reject 如果 Candidate.term < currentTerm
    • 如果 self.votedFor 为 null 或者 candidateId，并且 Candidate.log 不旧于自己（已 commit 的），就 vote（votedFor 为 candidateId 还要再发，是因为 消息可能乱序）

Append-Log RPC

  • 参数
    • term：leader.term
    • leaderId
    • prevLogIndex：下面 entries[] 之前的 entry 的 index
    • prevLogTerm：下面 entries[] 之前的 entry 的 term
    • entries[]：empty 表明 heartbeat
    • leaderCommit
  • 返回值
    • term：currentTerm ，Leader 落后，让其更新自己
    • success：true 表明 prevLogIndex 和 prevLogTerm match 并更新
  • 接受者规则
    • 返回 false 如果 Leader.term < currentTerm
    • 返回 false 如果 prevLogIndex 和 prevLogTerm 对不上
    • prevLogIndex 和 prevLogTerm 对上之后，后面全部替换为 entries[]
    • 如果 leaderCommit > self.commitIndex，就设置 self.commitIndex = min(leaderCommit, last index of log)

AppenLog Consistence

在这里插入图片描述

每次发送 entries[] 和 之前一项的 term + index。
如果 prevLogTerm + prevLogIndex 全部吻合，那么之后就替换或者追加；如果不吻合，就再往前发。

文中说有一个优化，如果不匹配，Follower 可以返回冲突 entry 这个 term 的第一个 index，然后 Leader 就可以跳过这个 term 的所有冲突 entry。这个没有搞懂，因为你还不能知道 Follower 在这个 term 中同步（commit）到哪个位置。

proof：我们限制 Leader 一定保有所有 commited 的 log，并且最终一定会有 Candidate win

commit 一定是超过半数的结点通过，那么只要注意到最后一波 commit 的这些结点不可能给其他结点 vote，最终成为 Leader 一定是最后一波 commit 之中的。

Leader 只 commit 自己的 log，前面的根据 Log-Matching Protocol 自动同步了

Leader 当选后通常会 send dummy log，来同步之前 term 的 log

Cluster membership changes 关于集群成员变更

这里只讨论 single change，即每次只加入/移除一个结点。

在这里插入图片描述

上图表明 加入/移除 一个结点分别在当前数量是 奇/偶 的情况。成员变更将整个集群分为两种认知，在这两种认知中的 majority 一定交非空，所以保证了不会在同一个 term 中出现不同的 leader

使用 Configuration log entry 来同步

感觉 c, d 好像写反了

Log Compaction

在这里插入图片描述

Reference

Raft 博士论文 CONSENSUS: BRIDGING THEORY AND PRACTICE

rsy56640
关注
专栏目录
《RAFT-Stereo：Multilevel Recurrent Field Transforms for Stereo Matching》论文笔记
m_buddy的博客
10-18 2363
参考代码：RAFT-Stereo 1. 概述 导读：RAFT算法是非常经典的立体匹配算法，在光流和立体匹配任务中有着广泛的运用。而这篇文章正是基于RAFT并将其运用到了立体匹配中，并且在如下的几个方面进行改进： 1）相比原生的RAFT算法钟重点关注X轴（W方向）的视差信息，前提是输入的图像对需要事先经过极线校准； 2）在GPU的update阶段使用stride为[8,16,32][8,16,32][8,16,32]的特征图进行运算，这样可以在迭代优化的同时更加增大网络感受野，从而增加对与大范围无/弱纹理区
《RAFT：Recurrent All-Pairs Field Transforms for Optical Flow》论文笔记
m_buddy的博客
07-09 1727
参考代码：RAFT 1. 概述 导读：这篇文章提出了一种新的光流估计pipline，与之前介绍的PWC-Net类似其也包含特征抽取/correlation volume构建操作。在这篇文章中为了优化光流估计，首先在correlation volume的像素上进行邻域采样得到lookups特征（增强特征相关性），之后直接使用以CNN-GRU为基础的迭代优化网络，在完整尺寸上对光流估计迭代优化。这样尽管采用了迭代优化的形式，文章的迭代优化机制也比想IRR这类方法轻量化，运行速度也更快，其可以在1080 TI
raft 经典论文
05-26
在分布式环境中，保证数据一致性，是系统可用性和可靠性的保障。最近一致在学习Diego Ongaro的大作“A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY”
Raft论文
yh88623131的博客
03-06 788
Faft论文
【论文阅读】RAFT: Adapting Language Model to Domain Specific RAG
最新发布
qq_41502855的博客
07-02 433
这篇论文主要是研究如何提升RAG中pre-trained LLM在垂域知识中的开卷考试的能力，提出了一种名为“RAFT”的训练范式。RAG的一个挑战在于，检索内容中同时包含golden document（正确的文档）和distractor documents（相关但非正确的混淆文档）时，大模型可能会从distractor document中抽取出错误回答。RAFT通过构造COT类型的QA对数据集来微调模型，从而提升大模型的推理能力。
Raft 论文
我喜欢雨天的清新的博客
10-09 250
Raft 一致性算法   Raft 是一种管理分布式log同步的算法。Raft的强一致性实现主要通过选举一个分布式leader节点，接着这个leader 完成管理分布式log的责任。这个leader 接受来自于client端的请求，它负责同步这个请求日志（log entries）到其他server中，并且还负责告诉其他server 何时可以安全的执行这个请求日志在它们的状态机中。有一个leader...
Raft 论文研读
brianleelxt的博客
06-20 695
Raft 论文研读 说明：本文为论文 《 In Search of an Understandable Consensus Algorithm (Extended Version) 》 的个人理解，难免有理解不到位之处，欢迎交流与指正 。 论文地址：Raft Paper 1. 复制状态机 复制状态机 (Replicated state machine) 方法在分布式系统中被用于解决 容错问题 ，这种方法中，一个集群中各服务器有相同状态的副本，并且在一些服务器宕机的情况下也可以正常运行 。 如上图所示，每
raft论文(四)
wsqyz的博客
02-21 664
Safety 上面的章节，关于raft的特性，已经讨论了Election Safety， Log Matching， Leader Append-only。接下来，我们先讨论Leader Completeness。 Leader Completeness 首先，再次回顾对Leader Completeness的定义： 如果一个日志entry在给定的任期已经被提交， 那么这个日志entry必然会出现在所有任期大于这个给定任期的leaders的日志中 对Leader Completeness，首先在选举的时候
CockroachDB: The Resilient Geo-Distributed SQL Database 论文阅读笔记
void
05-31 838
前言 本文绝大部分内容源自 CockroachDB 论文。 介绍 CockroachDB 是一个可扩展（Scalable）的 SQL DBMS，它主要用于支撑 OLTP 工作流，并保持高可用性（High Availability）和强一致性（Strong Consistency）。论文主要呈现了 CockroachDB 创新的事务模型，它在商用硬件上支持一致（Consistent）的分布式事务。 论文在 Introduction 提出了一个情景：一个公司在欧洲和澳洲有一个大用户基数，并且美国的用户数也在迅速
CMU15-721 《What’s really new with NewSQL》论文阅读笔记
小凯的博客
05-01 888
Study Notes on Course1 Video-bilibili Course Topics Focus on internals of single nodes in-memory database system. Not distributed Systems. 论文阅读笔记 《What’s really new with NewSQL》 NoSQL 传统关系模型与强事务保证制约...
分布式学习笔记1-分布式算法Raft
自由之路
03-01 720
简介 Raft是今比较流行的一个分布式选举算法。在它出来之前，业界只有Paxos一种算法。但是Paxos是非常难以理解，更不用说有统一的算法方案。Raft的出现，就是为了提供一个通俗易懂，容易实现的分布式方案。研究论文和相关源码已久，写下此文笔记，希望能对你也有一些启发。 基本原理 Server状态 集群的每个机器可以有3种角色状态 Leader 每个集群只能有一个，处理所有client的请求，...
raft算法，英文原版论文
03-24
raft算法，原版论文，英文版 摘要 Raft 是一种用来管理日志复制的一致性算法。它和 Paxos 的性能和功能是一样的，但是它和 Paxos 的结构不一样；这使得 Raft 更容易理解并且更易于建立实际的系统。为了提高理解性，Raft 将一致性算法分为了几个部分，例如领导选取（leader selection），日志复制（log replication）和安全性（safety），同时它使用了更强的一致性来减少了必须需要考虑的状态。从用户学习的结果来看，Raft 比 Paxos 更容易学会。Raft还包括了一种新的机制来使得动态改变集群成员，它使用重叠大多数（overlapping majorities）来保证安全。
Raft 一致性算法论文译文
03-15
Raft 是一种用来管理日志复制的一致性算法。它和 Paxos 的性能和功能是一样的，但是它和 Paxos 的结构不一样；这使得 Raft 更容易理解并且更易于建立实际的系统。为了提高理解性，Raft 将一致性算法分为了几个部分，例如领导选取（leader selection），日志复制（log replication）和安全性（safety），同时它使用了更强的一致性来减少了必须需要考虑的状态。从用户学习的结果来看，Raft 比 Paxos 更容易学会。Raft 还包括了一种新的机制来使得动态改变集群成员，它使用重叠大多数（overlapping majorities）来保证安全。
raft论文总结
qq_37026934的博客
11-30 2020
文章目录前言abstractintroducereplicated stat machineswhat's wrong with PaxosDesigning for understandabilityThe Raft consensus algorithm 前言 这篇论文发表于2014年讲述的是raft协议，raft协议是保证数据一致性和fault-tolerance的协议，常用于分布式系统中，大家应该知道设计一个分布式系统，我们首先要考虑fault-tolerance的问题，也就是一个节点down了如何
Raft论文简述
victorika的博客
01-16 679
目的 根据论文的实现来看，我认为Raft和Paxos这些一致性算法是为了解决分布式里状态机同步的问题。最典型的应用分布式里的容错，你的所有server都需要有备份，如果是有带状态的server，那么master和secondary之间的数据如何保持一致性就是一个难题，而这些算法就是为了解决这个问题的。 前言 这里稍微提一下，一般来说同步状态机，有以下两种方案。 1.State Machine。将完整的状态同步。 2.Replicated Machine。假设没有外因的情况下，对一样的状态机输.
Raft论文总结
Yaoman753的博客
04-30 463
raft论文总结 为什么需要对大规模的数据集进行存储和计算？ 当用户量扩大，请求响应和存储安全需求越来越高，单一服务器已经无法满足实际的使用情况。 解决方法有二： 1.换一台更好的服务器 2.多几台服务器一起用 从利润和技术的角度出发，后者比前者更容易实现。多台服务器一起来处理用户的请求，保存用户的信息。用户的每一个请求落实到数据库中就是一次增删改查，抽象出来就是一条对数据操作的指令。而将这些指令操作进行提交运行并存储每一条指令的结果，就是服务器的基本功能。但是服务器很可能同时接收到多条
Raft论文解读
weixin_46253576的博客
07-07 384
raft论文阅读
raft协议 论文
ppvqq的博客
11-20 1338
概述 raft通过操作日志备份的方式实现一致性算法。在达到的效果和可用性上与paxo相比没有什么区别，但是思维方式却有很大的不同；raft比paxos更容易理解，也更容易在此基础上工程化。为了便于理解，raft将一致性算法分解成了几个关键部分，例如，leader选举、操作日志分发备份、算法安全等，另外，为了更高强度的一致性（弱一致性----->强一致性，状态越少，速度越快，一致性越能得到
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值