分享
技术分享 《分布式一致性raft算法实现原理》
rfyiamcool · · 5907 次点击 · · 开始浏览这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。
这段时间跟同事聊了不少分布式系统中的常用算法协议,中间有聊到分布式一致性的话题,当然我们对一致性理解都是那种介绍的层次。 哈哈 , 后来用了心思去学习分布式一致性协议 raft, 现在有些心得,就拿出来给同事分享下。
先简单聊下什么是raft协议. 他用来做什么的? 分布式存储系统通常会维护多个副本,这样不仅能提高系统的可用性,因为有多个副本所以性能也有提高。但是多副本带来的代价就是分布式存储系统的核心问题之一: 需要维护多个副本的数据一致性。 Raft一致性协议就是用来干这事的,即使在部分副本宕机的情况下,只要符合raft的原则,照样可以对外提供服务。
Raft是一种较容易理解的一致性协议。 我曾经也写过工夫去学习paxos, 结果.... 我想大家都懂的,没搞明白。 学习paxos的过程是有些痛苦的,国内的一些文档说的不明不白的,国外的文档又太有深度。。。现在只是浅薄的看懂他在正常情况下的选举,日志复制,分区容错,但是paxos对于错误的处理,有不少知识点不是很理解。
Raft是个好东西呀,我以前用的influxdb,现在用的etcd,consul 都是采用Raft来确保数据的一致性。 为了做raft的话题分享,硬着头皮看了国外的raft说明文档,有些醉心. 我一般分享不会录制视频,所以尽量会把ppt做的详细点,有点raft基础的人,应该可以流畅的看下去。
PDF地址:
http://static.xiaorui.cc/raft_design.pdf
slideshare.net:
[フレーム]
Raft from rfyiamcool
slideshare是需要翻墙才能访问的,另外把 Raft分享的摘要贴出来。
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
1.分布式一致性raft实现原理-峰云就她了-xiaorui.cc
2.什么是一致性协议?raft有哪些特点?raft vs paxos?raft的构成组件及实现原理?各种所谓奇葩的raft场景?如何实现raft?介绍
3.单节点环境client server存在数据一致性问题?
4.多节点环境node1node3node2那么如何保证数据的一致性?
5.角色Follower Candidate Leader
6.KeyWorld定时器Term时间片Term IDN/2+1Heartbeats
7.KeyWorld选举成Leader需提供TermID和LogIndex Leader绝对不会删除自己的日志客户端自己携带ID帮助raft保持幂等性一条记录提交了,那么它之前的记录一定都是commited.
8.KeyWorld节点之间的Term和索引一致,我们就认为数据是一致的.在一个Term里只会有一个Leader每个Follower只能选一个Leader
9.KeyWorld currentTerm服务器最后一次知道的任期号(初始化为0,持续递增)voteFor在当前获得选票的候选人的Idlog[]日志条目集(状态机指令及TermId)commitIndex已知最大的索引值nextIndex[]每个follower的下一个索引值
10.Vote RPC Term候选人的任期号candidateid IDlastLogIndex候选人的最后日志的索引值lastLogTerm候选人最后日志的任期号Term当前的任期号,用于领导人去更新自己voteGranted TrueorFalse
11.most simple election vote forme vote forme OK!OK!
12.C-1simple electionF-2F-1vote forme vote forme NO timer155Term2Timer170Term3Condition比Follwer的term id小不影响"F"定时器在转!C已得知情况,故意Vote超时,等他人选举.Timer183Term3
13.C-1simple election RequestVote(term=2)voteGranted=true,term=2C-2same term idwait timeout!NO!Term notmatch RequestVote(term=2)
14.hard election-1vote forme OK!vote forme notterm match term conflict notn/2+1OK!都变为一个term id!
15.summery election过程定时器触发,followers把current_term_id+1改变成candidate状态发送RequestVoteRPC请求结果成功选举别人被选重新选
16.Client Works withleader Leader returnto response when it commits an entry!Assign uniquqeID to every command,Leader store latest IDwithresponse.
17.client process Only log entry!1Hello2Raft1Hello2Raft1Hello2Raft
18.Log Replication默认心跳为50ms默认心跳超时为300ms每次心跳的时候做Log entry commit超过n/2+1就算成功
19.Log RPC Term领导人的任期号LeaderID领导人的Id,以便于跟随者重定向请求pervLogIndex新的日志条目紧随之前的索引值entries[]需要存储当然日志条目(表示心跳时为空;一次性发送多个是为了提高效率)LeaderCommit领导人已经提交的日志的索引值Term当前的任期号,用于领导人去更新自己success跟随者包含了匹配上prevLogIndex和prevLogTerm的日志时为真
20.log replication-1Heartbaet&Append Entries1 Hello1Hello1Hello Heartbaet&Append Entries Only log entry!
21.log replication-2OK!1Hello1Hello1Hello OK!Leader commit!
22.Le_1 log replication-3F_2 F_1 Heartbaet&commit1 Hello Heartbaet&commit1Hello1Hello Follower commit!
23.常见疑难杂症
24.Le_1 ifanode reply timeout?F_2 F_1 Heartbaet&commit1Hello1Hello1Hellotimeout!!!F_2如何保持数据一致性?Leader会重试!
25.Le_1 Leader crash F_2 F_1 Log entry Ack1Hello1Hello1Hello Leader在本地commit后,发给follower commit之前crash!Hello还在么?F_31Hello
26.Le_1 Follower crash F_2 F_1 prevLogIndex1Hello2Raft F_3 crash重新启动后如何平衡数据.F_31Hello2Raft1Hello2Raft1Hello2
27.Network Partition
28.Le_1正常情况F_2 F_1 Heartbaet&commit1Hello F_3 F_41Hello1Hello1Hello1Hello
29.Le_1网络分区F_2 F_1 Request Vote1Hello F_3 F_41Hello1Hello1Hello1Hello两个人怎么够法定人数!!!Vote Granted
30.Le_1新集群正常F_2 F_1 Heartbeat&Log entry&commit1Hello2Tim F_3 F_41Hello2Ying1Hello2Ying1Hello2Tim1Hello2Ying两个人怎么够法定人数!!!
31.Le_1网络恢复F_2 F_1 Heartbeart&Append Log Entries1Hello Le_2 F_41Hello2Ying1Hello2Ying1Hello1Hello2Ying网络好了后,开始抢夺Leader Le_1 term小于Le_2!
32.一致性F_2 F_1 Heartbeat&Log entry&commit Le_2 F_41Hello2Ying1Hello2Ying1Hello2Ying F_51Hello2Ying1Hello2Ying
33.冲突Split brain如符合法定人数并产生了N条数据与新集群怎么保持数据一致性覆盖VS合并?被分区前有些node没有收到commit?timer check
34.预防Split brain单播制定节点指定法定人数,每次addreduce都需要更改加大timeout,retry统一client入口,But...监控脑裂情况,反查各个node的leader是否一致
35.复杂一致性12345678910S14444556677808990S244445566778089S34444556677S444445570708585S5444455707085index Host term id每个方格为Log entry
36.Log compress12345678910S14444556677808990index Snapshot Last included index:6Last included term:80state macheie state:x<—0y<—9allcommited!!!
37.study动画演示:https://ongardie.github.io/raft-talk-archive/2015/buildstuff/raftscope-replay/文档:http://en.youscribe.com/catalogue/tous/professional-resources/it-systems/raft-in-search-of-an-understandable-consensus-algorithm-2088704Googole...
38.Q&A
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信5907 次点击
添加一条新回复
(您需要 后才能回复 没有账号 ?)
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传
收入到我管理的专栏 新建专栏
这段时间跟同事聊了不少分布式系统中的常用算法协议,中间有聊到分布式一致性的话题,当然我们对一致性理解都是那种介绍的层次。 哈哈 , 后来用了心思去学习分布式一致性协议 raft, 现在有些心得,就拿出来给同事分享下。
先简单聊下什么是raft协议. 他用来做什么的? 分布式存储系统通常会维护多个副本,这样不仅能提高系统的可用性,因为有多个副本所以性能也有提高。但是多副本带来的代价就是分布式存储系统的核心问题之一: 需要维护多个副本的数据一致性。 Raft一致性协议就是用来干这事的,即使在部分副本宕机的情况下,只要符合raft的原则,照样可以对外提供服务。
Raft是一种较容易理解的一致性协议。 我曾经也写过工夫去学习paxos, 结果.... 我想大家都懂的,没搞明白。 学习paxos的过程是有些痛苦的,国内的一些文档说的不明不白的,国外的文档又太有深度。。。现在只是浅薄的看懂他在正常情况下的选举,日志复制,分区容错,但是paxos对于错误的处理,有不少知识点不是很理解。
Raft是个好东西呀,我以前用的influxdb,现在用的etcd,consul 都是采用Raft来确保数据的一致性。 为了做raft的话题分享,硬着头皮看了国外的raft说明文档,有些醉心. 我一般分享不会录制视频,所以尽量会把ppt做的详细点,有点raft基础的人,应该可以流畅的看下去。
PDF地址:
http://static.xiaorui.cc/raft_design.pdf
slideshare.net:
[フレーム]
Raft from rfyiamcool
slideshare是需要翻墙才能访问的,另外把 Raft分享的摘要贴出来。
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
1.分布式一致性raft实现原理-峰云就她了-xiaorui.cc
2.什么是一致性协议?raft有哪些特点?raft vs paxos?raft的构成组件及实现原理?各种所谓奇葩的raft场景?如何实现raft?介绍
3.单节点环境client server存在数据一致性问题?
4.多节点环境node1node3node2那么如何保证数据的一致性?
5.角色Follower Candidate Leader
6.KeyWorld定时器Term时间片Term IDN/2+1Heartbeats
7.KeyWorld选举成Leader需提供TermID和LogIndex Leader绝对不会删除自己的日志客户端自己携带ID帮助raft保持幂等性一条记录提交了,那么它之前的记录一定都是commited.
8.KeyWorld节点之间的Term和索引一致,我们就认为数据是一致的.在一个Term里只会有一个Leader每个Follower只能选一个Leader
9.KeyWorld currentTerm服务器最后一次知道的任期号(初始化为0,持续递增)voteFor在当前获得选票的候选人的Idlog[]日志条目集(状态机指令及TermId)commitIndex已知最大的索引值nextIndex[]每个follower的下一个索引值
10.Vote RPC Term候选人的任期号candidateid IDlastLogIndex候选人的最后日志的索引值lastLogTerm候选人最后日志的任期号Term当前的任期号,用于领导人去更新自己voteGranted TrueorFalse
11.most simple election vote forme vote forme OK!OK!
12.C-1simple electionF-2F-1vote forme vote forme NO timer155Term2Timer170Term3Condition比Follwer的term id小不影响"F"定时器在转!C已得知情况,故意Vote超时,等他人选举.Timer183Term3
13.C-1simple election RequestVote(term=2)voteGranted=true,term=2C-2same term idwait timeout!NO!Term notmatch RequestVote(term=2)
14.hard election-1vote forme OK!vote forme notterm match term conflict notn/2+1OK!都变为一个term id!
15.summery election过程定时器触发,followers把current_term_id+1改变成candidate状态发送RequestVoteRPC请求结果成功选举别人被选重新选
16.Client Works withleader Leader returnto response when it commits an entry!Assign uniquqeID to every command,Leader store latest IDwithresponse.
17.client process Only log entry!1Hello2Raft1Hello2Raft1Hello2Raft
18.Log Replication默认心跳为50ms默认心跳超时为300ms每次心跳的时候做Log entry commit超过n/2+1就算成功
19.Log RPC Term领导人的任期号LeaderID领导人的Id,以便于跟随者重定向请求pervLogIndex新的日志条目紧随之前的索引值entries[]需要存储当然日志条目(表示心跳时为空;一次性发送多个是为了提高效率)LeaderCommit领导人已经提交的日志的索引值Term当前的任期号,用于领导人去更新自己success跟随者包含了匹配上prevLogIndex和prevLogTerm的日志时为真
20.log replication-1Heartbaet&Append Entries1 Hello1Hello1Hello Heartbaet&Append Entries Only log entry!
21.log replication-2OK!1Hello1Hello1Hello OK!Leader commit!
22.Le_1 log replication-3F_2 F_1 Heartbaet&commit1 Hello Heartbaet&commit1Hello1Hello Follower commit!
23.常见疑难杂症
24.Le_1 ifanode reply timeout?F_2 F_1 Heartbaet&commit1Hello1Hello1Hellotimeout!!!F_2如何保持数据一致性?Leader会重试!
25.Le_1 Leader crash F_2 F_1 Log entry Ack1Hello1Hello1Hello Leader在本地commit后,发给follower commit之前crash!Hello还在么?F_31Hello
26.Le_1 Follower crash F_2 F_1 prevLogIndex1Hello2Raft F_3 crash重新启动后如何平衡数据.F_31Hello2Raft1Hello2Raft1Hello2
27.Network Partition
28.Le_1正常情况F_2 F_1 Heartbaet&commit1Hello F_3 F_41Hello1Hello1Hello1Hello
29.Le_1网络分区F_2 F_1 Request Vote1Hello F_3 F_41Hello1Hello1Hello1Hello两个人怎么够法定人数!!!Vote Granted
30.Le_1新集群正常F_2 F_1 Heartbeat&Log entry&commit1Hello2Tim F_3 F_41Hello2Ying1Hello2Ying1Hello2Tim1Hello2Ying两个人怎么够法定人数!!!
31.Le_1网络恢复F_2 F_1 Heartbeart&Append Log Entries1Hello Le_2 F_41Hello2Ying1Hello2Ying1Hello1Hello2Ying网络好了后,开始抢夺Leader Le_1 term小于Le_2!
32.一致性F_2 F_1 Heartbeat&Log entry&commit Le_2 F_41Hello2Ying1Hello2Ying1Hello2Ying F_51Hello2Ying1Hello2Ying
33.冲突Split brain如符合法定人数并产生了N条数据与新集群怎么保持数据一致性覆盖VS合并?被分区前有些node没有收到commit?timer check
34.预防Split brain单播制定节点指定法定人数,每次addreduce都需要更改加大timeout,retry统一client入口,But...监控脑裂情况,反查各个node的leader是否一致
35.复杂一致性12345678910S14444556677808990S244445566778089S34444556677S444445570708585S5444455707085index Host term id每个方格为Log entry
36.Log compress12345678910S14444556677808990index Snapshot Last included index:6Last included term:80state macheie state:x<—0y<—9allcommited!!!
37.study动画演示:https://ongardie.github.io/raft-talk-archive/2015/buildstuff/raftscope-replay/文档:http://en.youscribe.com/catalogue/tous/professional-resources/it-systems/raft-in-search-of-an-understandable-consensus-algorithm-2088704Googole...
38.Q&A