08 | Raft算法(二):如何复制日志?
该思维导图由 AI 生成,仅供参考
如何理解日志?
- 深入了解
- 翻译
- 解释
- 总结
Raft算法是一种用于实现分布式系统中一致性的算法。本文深入讲解了Raft算法中的日志复制和一致性实现。文章首先介绍了日志的概念和组成,然后详细解释了Raft算法中如何复制日志,包括领导者发送日志复制RPC消息、应用日志项到状态机等过程。接着,文章阐述了在实际环境中可能遇到的日志不一致问题,以及Raft算法是如何处理不一致日志,实现日志的一致性的。最后,文章通过具体的步骤演示了领导者通过日志复制RPC一致性检查,找到跟随者节点上与自己相同日志项的最大索引值,然后复制并更新覆盖该索引值之后的日志项,实现了各节点日志的一致。整体而言,本文详细解释了Raft算法中日志复制和一致性实现的具体过程,对于想深入了解分布式系统一致性算法的读者具有很高的参考价值。文章内容涵盖了Raft算法中日志的重要概念和实现细节,为读者提供了深入了解分布式系统一致性算法的重要参考资料。
《分布式协议与算法实战》,新⼈⾸单¥59
全部留言(91)
- 最新
- 精选
- 花家舍置顶http://thesecretlivesofdata.com/raft/ 动画演示 比文章牛逼多了
编辑回复: 这个资源好,推荐
2020-03-13879 - Mars老师,我有个问题,在那个复制日志的五个过程里,如果第四步执行返回结果成功了,leader突然挂了,此时leader 的状态机已经更新,follower状态机没有更新,此时新选举出来的leader怎么处理这个流程来保证上一个leader的状态机更新apply到其他节点上了呢?
作者回复: 加一颗星:),领导者选举能保证新领导者一定包含这条committed的日志项,但这条日志项在新领导者上处于未提交状态,这时新领导者,会尝试从最新日志项开始,向其他节点复制日志,如果,某条uncommitted的日志项,被发现已经成功复制到大多数节点上,这时这条日志项将处于提交状态,并被应用到状态机,通知其他节点提交这条日志。
2020-03-112454 - Scott我有一个问题,考虑下面这种情况,假设集群有1 leader 多 follower 1. leader发出一条set x = 1,index为最新的appendEntries到所有的follower 2. 只有一台follower响应了,所以leader对client返回fail 3. 这时leader挂了,剩余机器重新进行选举,因为前面那台follower有最新的uncommited的日志,所以它会被选举为leader 这时就会有一个不一致,外部client认为set x = 1没有成功,但是实际上x = 1是成功的,这种情况合法吗?
作者回复: 加一颗星:),合法的,如果操作具有冥等性,比如“set x = 1”,就没关系,不影响结果,而且最后日志会去重压缩处理的,如果操作不具有冥等性,需要实现客户端协议,确保只提交一次。关于客户端协议,我后面会做补充。
2020-03-013336 - 葉月喵上一章跟随者投票时会比较日志索引号大小,用的是已提交的日志,还是已经复制的日志?
作者回复: 复制的,uncommited的。
2020-02-28226 - 阿kai(aeo感觉处理日志一致性问题的时候非常不efficient,如果follower落后得多了,那么来回的RPC大部分都是failure,很耗时间和带宽。follower是否可以直接返回它拥有的最新index,然后leader根据那个index开始看是否match自己的日志,如果match就直接一次性把剩余日志都给follower发过去。这样会有效率一些吧?
作者回复: 加一颗星:),这是个工程实现层面的优化方式:)
2020-03-16515 - piboye为什么跟随者不直接告诉领导者我从哪里缺日志,而让领导者一个一个去尝试?
作者回复: 加一颗星:),因为存在跟随者日志和领导者日志不一致的情况,这时领导者就不能只同步跟随者缺失的日志项,而是要先做日志一致性检查,如果日志项不一致,领导者要同步并覆盖掉跟随者节点上已存在但不一致的日志项。
2020-09-17210 - Geek_d40030老师您好,在日志更新的时候为什么有索引值了,还要判断任期呢?理论上索引值是单调递增的就能够判断跟随者的日志在什么位置吧。
作者回复: 加一颗星:),这是因为日志项可能来自不同的领导者,比如,节点A、B的索引值4对应的日志项,它的任期编号分别为1和2,那么,这两个日志项,就是2个不同的领导者创建的,即它们是不同的日志项。
2020-07-029 - DZ老师,请教下如果在指定时间内没有收到大部分follower复制成功响应,只收到少数,那么领导者如何处理这次提交?是直接不做任何处理,由心跳或者下次提交重新对齐日志?还是有重试或者rollback机制?
作者回复: 加一颗星:),此时日志项仍处于未提交状态,领导者需要继续重试,按顺序复制日志项,只有当日志项被成功复制到大多数节点时,该日志项处于提交状态,然后被应用到状态机。
2020-03-1959 - bc客户端并不知道谁是leader,怎么保证客户端的请求一定是由lead来处理的?
作者回复: 加一颗星:)。一般有2种实现方式:1. 接收到写请求的跟随者充当“代理”,转发写请求给领导者;2. 跟随者返回领导者信息给客户端,客户端再发起请求,直接联系领导者。在19、20讲,有更具体的分析。
2020-03-1128 - Jialin1.Raft 日志格式: • 指令:一条由客户端请求指定的、状态机需要执行的指令。即客户端提交的数据 • 索引值:日志项对应的整数索引值,用来标识日志项的,是一个连续的、单调递增的整数号码 • 任期编号:创建这条日志项的领导者的任期编号 2.理想的日志复制阶段: • 接收到客户端请求后,领导者基于客户端请求中的指令,创建一个新日志项,并附加到本地日志中 • 领导者通过日志复制 RPC,将新的日志项复制到其他的服务器 • 当领导者将日志项,成功复制到大多数的服务器上的时候,领导者会将这条日志项提交到它的状态机中 • 领导者将执行的结果返回给客户端 • 当跟随者接收到心跳信息,或者新的日志复制 RPC 消息后,如果跟随者发现领导者已经提交了某条日志项,而它还没提交,那么跟随者就将这条日志项提交到本地的状态机中 3.实际生产环境中,复制日志的时候遇到进程崩溃、服务器宕机等问题,这些问题会导致日志不一致。Raft 算法按照“Raft 是通过以领导者的日志为准,来实现各节点日志的一致的”原则处理不一致日志,实现日志的一致,具体如下: • 领导者通过日志复制 RPC 的一致性检查,找到跟随者节点上与自己相同日志项的最大索引值。也就是说,这个索引值之前的日志,领导者和跟随者是一致的,之后的日志是不一致的了。 • 领导者强制跟随者更新覆盖的不一致日志项,实现日志的一致 课后思考题:领导者接收到大多数的“复制成功”响应后,就会将日志提交到它自己的状态机,然后返回“成功”响应客户端。如果此时有个节点不在“大多数”中,也就是说它接收日志项失败,那么在这种情况下,Raft 会通过日志复制 RPC 的一致性检查,找到失败者节点上,与自己相同日志项的最大索引值,然后领导者强制该失败者更新覆盖的不一致日志项,实现日志的一致
作者回复: 加一颗星:)
2020-02-287