raft分布式一致性算法

raft算法可以作为很多服务实现一致性的指导协议。

为什么要一致性?

单台服务器,用户访问服务器,服务器做事,成功/失败的状态和用户都会达成一致的共识。

多台服务器,为了和用户随时保持共识,就要在集群内部通过互相沟通,然后把结果输出给用户,才能达成共识。

共识的对于用户来说,就是系统的信用,系统说a已经做了,那么如果a没有做,用户被骗,这个系统就没有存在的意义。

那么服务器内部的怎么沟通能保证一致性?

raft协议下的集群会有一个leader作为代表,负责和用户沟通,代表保证内部口径一致的方式是对于用户的一个意见(操作)进行投票,赞成票多就通过,实际不会有服务器试图投反对票,只有某个服务器在外力作用下失去投票能力。这里用的是,比较常见的两段式提交

面对失去leader的问题时,集群内部服务器都会试图申请作为下个leader(源码中使用随机timeout减小冲突),票多者当选,当然参选人有前提条件,就是参选人一定知道过去所有已经通过的决议,否则不能和用户达成共识,因为当选后,是需要和大家同步过去所有决议的。

技术细节

首先,服务器之间,通过自定义的协议沟通,沟通的主要内容包括:

  • leader保持自己身份的心跳,需要同步的数据随心跳发送
  • 选举时,发起投票和投票的途径

现实生活中就是说话,只是不允许废话而已。协议的载体可以是tcp/http,无所谓。

其次,服务器需要把通过的用户决议备案(持久化),这里一般就是写磁盘,两段式提交允许集群内部口头达成后就立即通知用户,不需要等到备案,毕竟这里没有阴谋论,大家都会为达成共识竭尽全力(真正备案时出问题概率小)。当然用户也可以选择做稳妥的方式,备案后在告诉他,这个方案会牺牲性能。

服务器数量是奇数保证每次投票都是不平衡的,这高效,同时避免出现集团纷争(两组服务器同样数量同样的投票权,如果分别开自己的会议,对外就不是一致的);票选中大多数这个概念很重要,也是为了高效;发起决议时也需要大多数的规则在里面。

上面的描述可能你还不是很了解,那么看下下面的参考内容,算法可以理解为从实际社会里真实存在的策略抽象出来,其中的技术小细节,类似team和vote,沟通方式等,都可以对应到真实会议中的动作,只是真实会议更复杂(阴谋论)。

香港科技大学一个学生的描述

痴迷于分布式一致性的技术达人,写的直观的例子

raft分布式一致性算法
Share this