湘潭网站建设优化建站,专业建设网站制作,国土 住房与城乡建设部网站,移动wap网站转载自 分布式一致性算法#xff1a;可能比你想象得更复杂分布式系统的难题张大胖遇到了一个难题。他们公司的有个服务器#xff0c;上面保存着宝贵的数据#xff0c;领导Bill 为了防止它挂掉#xff0c; 要求张大胖想想办法把数据做备份。张大胖发挥了抽象的能力#xff…转载自 分布式一致性算法可能比你想象得更复杂分布式系统的难题张大胖遇到了一个难题。他们公司的有个服务器上面保存着宝贵的数据领导Bill 为了防止它挂掉 要求张大胖想想办法把数据做备份。张大胖发挥了抽象的能力在脑海里浮出了这么一个画面 这个唯一的机器可以成为一个节点为了提高可用性可以增加几台机器通过局域网连接起来形成一个了分布式的系统数据在每个节点上都存放一份不就可以高枕无忧了可张大胖很快发现这不是一件容易的事情比如每个节点都保存着一个账户的余额100元现在有人通过节点A向该账户增加了20元 还有人通过节点B向该账户减去了30元。现在余额到底是多少呢为了保持一致性 节点A得把余额加上20这样的消息发给B, C 节点B得把“余额减去30”这样的消息发送到A, C 如果网络出了问题消息没有发送到别的节点 或者某个节点干脆坏掉了那数据极有可能出现不一致。如果用户在这个不一致的系统上继续操作很快就会陷入混乱。2谁来当老大张大胖想了半天觉得不能这么无序地操作得给这三个节点找个“老大”。所有的操作都通过“老大”来进行然后让老大把消息发给各个“小弟”。可是谁来当老大呢 还有这个老大如果挂掉了怎么办可以手工地调整 例如节点A挂掉了 就手工地让节点B当“老大” 让节点C当“小弟”。但是这就有点麻烦了能不能自动化地来实现这个问题很有意思 张大胖入了迷继续深入思考 建立一个竞选的机制 就让他们竞争上岗吧。初始情况下每个节点都是候选人 都可以向其他节点发起投票邀请让大家投自己如果获得的投票数过半就可以当“老大”了。为了避免大家同时发起投票邀请可以给每个节点都分配一个随机的“选举超时时间”election timeout通俗来讲就是一个等待时间在这段时间内一个节点必须耐心等待过了这段时间才可以竞争上岗争当老大。每个节点都有一个计时器从0开始计时谁的等待时间到了, 就率先发起竞选给其他节点打电话要求他们投票让自己成为老大。比如节点A等待170ms , 节点B等待200ms , 节点C等待250ms 。由于节点A的等待时间最短 会捷足先登 它先增加自己的任期(Term)这是一个整数初始值为0 然后给自己投了一票然后打电话给节点B和节点C要求他们都投它。节点B和节点C收到了投票要求如果自己还没有发起竞选投票等待时间未到那只好同意节点A当老大与此同时要重置自己的计时器重新从0开始计时也就是说重新开始新一轮的等待。节点A得知其他两个节点同意了投票计数变为3已经过了半数 就明白自己可以当老大了。节点A成为老大后开始向节点B和节点C定时发送消息B,C收到消息后也要回应维持心跳。B和C每次收到心跳消息都得重置自己的计时器 重新从0开始计数。此时节点B和节点C就成了“小弟”。如果节点A 不幸挂掉节点B和节点C在自己的等待时间内收不到心跳消息他们两个就会重新竞争上岗。上图中节点C占据了先机率先发起竞选投票。节点B慢了一步 无奈中同意支持节点C 节点C获得了超过半数的支持成为“老大” 节点B成为“小弟”。可能有人会想到节点B和节点C 同时发起竞选投票每个节点的投票计数都是1 都过不了半数 该怎么处理呢 很简单再次发起一轮竞选投票即可当然为了防止B和C一直同时发起竞选投票从而陷入无限循环要重置一个随机的等待时间。投票过半数很重要张大胖想只有这样才能保证“老大”节点的唯一性。对于每个节点处理流程其实非常简单3数据的复制张大胖费了半天劲终于把分布式系统中怎么自动地选取“老大”节点给确定了。接下来就是要把发给“老大”的数据想办法复制到“小弟”的节点上。 该怎么处理由于是分布式的只有大多数节点都成功地保存了数据才算保存成功。所以那个“老大”节点必须得承担起协调的职责。张大胖想了一个复制日志的办法 每个节点都有一个日志的队列。在真正把数据提交之前先把数据追加到日志队列中然后向个“小弟”复制。1. 客户端发送数据给节点A “老大”。
节点A 先把数据记录到日志中即此时处于“未提交状态”2. 在下一次的心跳消息中 数据被发送给各个“小弟”。3. 各个“小弟” 也把数据记录到日志中也处于未提交状态然后向“老大”报告自己已经记录了日志。4. 如果节点A收到响应超过了半数 节点A就提交数据通知客户端数据保存成功。5. 节点A在下一次心跳消息中通知各个“小弟”该数据已经提交。各个“小弟”也提交自己的数据。如果某个“小弟”不幸挂掉那“老大”会不断地尝试联系它 一旦它重新开始工作就需要从“老大”那里去复制数据和“老大”保持一致。4RAFT张大胖对这个初步的设计还比较满意他把这个方案交给领导Bill去审查。Bill 看了以后笑道 “你现在其实就是在折腾一个一致性算法 说白了就是允许一组机器像一个整体一样工作即使其中一些机器出现故障也能够继续工作下去。”“没错没错领导总结得真是精准。” 张大胖拍马屁。“不过”Bill 话锋一转 “ 你设计的日志的复制还有很多漏洞我看你的设计中一共有5步 如果在这5步中那个“老大”节点A挂掉了怎么办数据是不是就不一致了”“这个...... ” 张大胖确实没有仔细考虑。他暗自后悔只顾低头拉车忘了抬头看路忽略了分布式环境下的复杂问题。“不过你已经做得很不错了” 领导马上鼓励道 “你设计的这一套体系其实和RAFT算法非常类似。”“RAFT ”“对RAFT是个分布式的一致性算法相比复杂难懂的Paxos RAFT在可理解可实现性上做了很大的改进。 你这里的‘老大’RAFT算法叫做Leader ‘小弟’叫做Follower不过人家对日志的复制以及如何确保数据的一致性有着非常详细的规定。 ”张大胖一听说有现成的算法立刻高兴起来 “太好了分布式的难题已经被别人解决我去把它实现了。”后记 虽然RAFT比Paxos更容易理解 但是一旦进入各个边界条件仍然是非常复杂所以本文只是介绍了Leader的选举和日志复制的概要流程 具体的细节还有很多感兴趣的话可以去看看Raft的论文点击阅读原文可以查看中文版。
