6.824-lecture5

6.824 2017讲座5：筏（1）

我们为什么要阅读这篇论文？
分布式共识是人们数十年来一直努力解决的难题
实验2和3基于Raft

这个讲座
今天：筏选和日志处理（实验2A，2B）
下一页：筏持久性，客户端行为，快照（实验2C，实验3）

总体主题：使用复制状态机（RSM）的容错服务
[客户端，副本服务器]
示例：配置服务器，例如MapReduce或GFS主服务器
示例：键/值存储服务器，put（）/ get（）（lab3）
目标：对于用户来说看起来和单机一样
但尽管有一些故障服务器也可用（高可用）
战略：
每个副本服务器以相同的顺序执行相同的命令（顺序一致性）
因此它们在执行时仍所有副本相同
因此，如果一个失败，其他人可以继续
即出现故障时，客户端切换到另一台服务器，坏了就换到另一台
GFS和VMware FT都具有这种风格，套路类似

关键问题：如何避免脑裂？脑裂开问题
假设客户端可以联系副本A，但不能联系副本B
客户可以继续复制A吗？
如果B确实崩溃了，那么客户必须在没有B的情况下继续进行，
否则服务将无法容忍错误！
如果B启动，但网络阻止客户端与之联系，
也许客户不应该在找不到b时候继续进行，
尽管它可能还活着并服务于其他客户-但是缺冒着分裂大脑的风险

为什么不允许裂脑的示例：
容错键/值数据库
C1和C2位于不同的网络分区中，并与不同的服务器通信
C1：put（“ k1”，“ v1”）
C2：put（“ k1”，“ v2”）
C1：get（“ k1”）-> ???
正确的答案是“ v2”，因为这是非复制服务器将产生的结果
但是如果两个服务器由于分区而分别为C1和C2服务，
C1的获得可能会产生“ v1”

破坏了一致性

问题：计算机无法区分崩溃的计算机还是分区网络
都表现为无法与一台或多台计算机通信

对计算机来说，机器坏了和网络坏了结果是一样的

我们需要一种满足以下三个目标的状态机复制方案：
1.尽管有任何一次（故障停止）失败，但仍然可用
2.处理不带脑裂的分区
3.如果故障太多：等待维修，然后恢复

应对分区的最大见解：多数票 选举投票
2f + 1台服务器可以容忍f个故障，例如3台服务器可以容忍1个故障
必须获得服务器的多数（f + 1）ti同意取得进展，真理在大多数
f个服务器的故障留下了剩下的f + 1，可以继续进行，系统有冗余，部分崩溃不影响
为什么majority可以避免大脑分裂？
最多一个分区可以拥有多数
注意：大多数不在所有2f + 1服务器中，而不仅仅是实时服务器中
关于多数人真正有用的是，任何两个必须相交
交叉路口中的服务器只会以一种方式或另一种方式进行投票
交叉路口可以传达有关先前决策的信息

在1990年左右发明了两阶段可容忍分区的复制方案，
Paxos和带有视图标记的复制View-Stamped Replication
在过去的十年中，这项技术已在现实世界中得到了广泛应用
Raft是现代技术的很好的介绍

***主题：筏概述

Raft进行状态机复制-以实验3为例：
[图：客户端，3个副本，k / v层，raft层，日志]
服务器的Raft层选举一位领导者
客户端将RPC发送到Leader中的k / v层
放置，获取，附加
k / v层将请求转发到Raft层，尚未响应客户端
领导者的筏层将每个客户端命令发送到所有副本
通过AppendEntries RPC
每个关注者都追加到其本地日志（但尚未提交）
并回应领导者承认
如果多数人将记录输入领导者，则该记录变为“已提交”
保证它不会被遗忘
多数->将会在下一届领导人的投票请求中看到
领导者说已提交后，服务器会将操作应用于k / v状态机
他们通过下一个AppendEntries RPC（通过commitIndex）找到了相关信息
领导者在提交后对k / v层做出响应
k / v层适用于放入数据库或获取结果
然后领导者回覆执行结果的客户

为什么要日志？
服务保持状态机状态，例如键/值数据库
为什么还不够？
给命令编号很重要
帮助副本在单个执行顺序上达成一致
帮助领导者确保追随者拥有相同的日志
副本也使用日志存储命令
直到领导执行他们
因此，如果跟随者错过了一些机会，领导者可以重新发送
重启后的持久性和重播（下一次）

Raft的设计包含两个主要部分：
选举新领导人
即使有故障也能确保相同的日志

***主题：领导人选举（实验2A）

为什么要领导？
确保所有副本以相同顺序执行相同命令

raft使用“术语”对领导者的顺序进行编号
新领导人->新任期
一个任期至多有一位领导者；可能没有领导者
每次选举都与一个特定词相关
每时期只有一次成功的选举
术语编号有助于服务器跟随最新的领导者，而不是被取代的领导者

raft什么时候开始领导人选举？
AppendEntries是暗含的心跳；加领导定期发送
如果其他服务器没有收到来自当前领导者的“选举超时”消息
他们以为领导人下台并开始选举

找不到领导的心跳就选举下一个领导

[状态转换图，图4：关注者，候选人，领导者]
关注者增加本地currentTerm，成为候选人，开始选举
注意：这可能导致不必要的选举；那很慢但是很安全
注意：老领导者可能还活着，并认为它是领导者

服务器成为候选服务器时会发生什么？
三种可能性：
1）获得多数，转变为领导者
当地观察和计数选票
注意：不能抵抗拜占庭式的错误！
2）未能获得多数，听到另一位领导人的意见
通过传入的AppendEntries RPC
服从新领导人的权力，并成为追随者
3）未能获得多数，但没有收到新领导的来信
例如，如果在少数网络分区中
超时并开始另一次选举（仍是候选人）
注意：在情况（3）中，可以不断增加项
但无法添加日志条目，因为属于少数群体而不是领导者
一旦分区愈合，由于任期较长，选举便随之而来
但是：多数分区中的任一日志都较长（因此长期
候选人被拒绝），或者如果没有任何反应，则长度相同
在多数派中（因此高级候选人可以获胜，但不会造成伤害）

如何确保一个任期中最多一位领导者？
（图2 RequestVote RPC和服务器规则）
领导者必须获得大多数服务器的赞成票
每个服务器每学期只能投一票
给定期限，最多一台服务器可以获得多数票
->即使网络分区也最多一位领导
->即使某些服务器出现故障，选举也可以成功

新领导人如何建立自己的地位？
获胜者获得多数票赞成
立即向所有人发送AppendEntries RPC（心跳）
新领导人的心跳抑制了任何新的选举

选举可能不会成功，原因有两个：
*不到大多数服务器可以访问
*同时候选人以投票方式表决，没有人获得多数

如果选举不成功怎么办？
另一个超时（无心跳），另一个选举
高等级优先，高等级候选人退出

如何设置选举超时时间？
每个服务器随机选择一个选举超时
有助于避免投票分裂
随机性破坏了服务器之间的对称性
一个人会选择最低的随机延迟
避免每个人都同时开始选举，自己投票
希望有足够的时间在下次超时到期之前进行选择
其他人将看到新领导者的AppendEntries心跳和
没有成为候选人
什么值？
至少几个心跳间隔（网络可能会降低或延迟心跳）
足够长的随机部分，以使一个候选人在下一次开始之前能够成功
足够短，可以在测试人员感到不适之前重试几次
测试人员要求选择在5秒或更短时间内完成

***主题：筏日志（实验2B）

我们讨论了领导者如何复制日志条目
重要区别：复制项与提交项
保证提交的条目永远不会消失
复制，但未提交的条目可能会被覆盖！
帮助每个参与者思考一个明确的“提交边界”

服务器的日志将始终是彼此的精确副本吗？
否：某些副本可能会滞后
否：我们会看到他们可以临时输入不同的条目
好消息：
他们最终会融合
提交机制确保服务器仅执行稳定的条目

额外标准：领导者不能简单地复制并提交旧学期的条目
[图8示例]
S1无法将第2项的条目复制为多数，然后失败
S5成为第3学期的领导者，添加了条目，但未能复制它
S1回来，再次成为领导者
致力于从第2阶段复制旧条目，以迫使追随者采用其日志
一旦术语2条目在大多数服务器上，我们是否可以提交？
原来答案是否定的！考虑如果我们这样做会发生什么：
第2时期的条目已复制到S3
S1提交它，因为它在大多数服务器上
S1然后再次失败
S5被选为第4项，因为在日志末尾有第3项
日志末尾有第2项条目的每个人对S5的投票
S5成为领导者，现在将* 5 *日志（带有3项）强加给其他人
索引2的第2项条目将被第3项覆盖
但是应该承诺！
因此，与领导者完整性属性矛盾
解决方案：等到S1也已经复制并提交了第4项条目
确保如果S1失败，则不能再选举S5
因此现在也可以提交第二学期的报名

Raft何时覆盖日志条目合法？（请参见图7问题）
他们必须不作承诺
可能会截断并覆盖更长的日志
图7（f）就是一个例子
例如，领导者将许多条目添加到其日志中，但是无法复制它们
也许在网络分区中
其他领导者在以后的术语中添加相同索引的条目（图7（a）-（e））
并提交其中至少一些
现在无法再更改此日志索引
过时的服务器接收AppendEntries，覆盖未提交的日志条目
即使日志比当前领导者的日志长得多！
没关系，因为领导者仅在条目提交后才响应客户
因此在（f）中生成覆盖条目的领导者不能这样做

***附录：实验2raft界面

rf.Start（命令）（索引，术语，isleader）
实验3 k / v服务器的Put（）/ Get（）RPC处理程序调用Start（）
在新的日志条目上启动Raft协议
Start（）立即返回-然后RPC处理程序必须等待提交
如果服务器在提交命令之前失去领导权，则可能无法成功
isleader：如果此服务器不是Raft领导者，则为false，客户端应尝试其他
term：currentTerm，以帮助呼叫者检测领导者是否被降级
index：日志条目，以查看命令是否已提交
ApplyMsg，带有索引和命令
筏在“应用频道”上为每个应用发送一条消息
已提交的日志条目。然后，服务知道执行
命令，领导者使用ApplyMsg
知道何时/以何种方式回复等待的客户端RPC。