Raft

分布式系统常见问题之一致性

多系统之间要想保证一致性，毫无疑问同步是最强的一致性体现，但是同步严重降低了系统之间的可用性

C（consistency） 和 A（available）之间的取舍是当前分布式系统的困扰

Raft算法是什么？

Paxos一直是分布式协议的标准，但是Paxos难于理解，更难以实现，Google的分布式锁系统Chubby作为Paxos实现曾经遭遇到很多坑。后来斯坦福大学提出了Raft算法。

Raft是用于管理复制日志的一致性算法。它的效果相当于(multi-)Paxos，跟Paxos一样高效，但结构与Paxos不同。这使得Raft比Paxos更容易理解，也为构建实用系统提供了更好的基础。

Raft基础知识

Raft集群包含多个服务器，5个服务器是比较典型的，允许系统容忍两个故障。在任何给定时间，每个服务器都处于以下三种状态之一，领导者（Leader），追随者（Follower）或候选人（Candidate）。 这几个状态间可以相互转换。

Leader：处理所有客户端交互，日志复制等，一般一次只有一个Leader

Follower：类似选民，完全被动

Candidate：类似Proposer律师，可以被选为一个新的领导人

三个子问题：

Log Replication

Safety

2pc

leader Election

选举算法是利用时间窗口的来进行选举

无论集群有多少台机器

每一台集群在指定超时时间 结束前没有收到 leader的心跳，此机器认为集群中没有leader，此时就会发起对自己的投票

既然是每一台机器的都干的活，那么此时 集群中会有多台机器发起投票，发起投票的机器不对其他发起投票的机器做出相应，没有发起投票的机器只能接待最先达到的投票，并给出响应

一轮过去后，发起投票的所有机器中有可能有且仅有一台获得一半以上的票数,此时他就是leader，向集群发送心跳维持关系，其他发起投票机器和投给其他机器的机器收到leader的心跳包，此时认为给他发心跳包的机器就是leader。 如果发起投票的所有机器没有一台超过一半同意，那么超时进行第二轮选，票数重置

Log Replication

client发送一次请求

读请求

写请求

client 这些外部系统 发送写请求

1. 直接发给leader，那么leader日志备份，并同时发送写请求给集群， 集群 收到之后日志备份，返回 leader，leader此时提交，可以返回给客户端了，同时发送提交心跳包给集群，

   （leader 发给 集群，没有收到响应，重新退回候选，选出新leader后在进行 处理请求）

   （leader发送给集群，收到响应提交了，但是集群没收到提交包，leader又为候选，重选leader）

（leader发送给集群，收到响应提交了，但是集群只有少部分收到提交包，leader又为候选，重选leader）

赏

谢谢你请我吃糖果

支付宝

微信