背景
Paxos协议晦涩难懂,在工程实践中难以得到应用。Raft是一种分布式一致算法,是RaplicationAnd Fault Tolerant的缩写。Raft相对来说容易理解,容易应用到工程实践中去。所以Raft会大行其道。
Raft协议
- Raft的协议主要包含以下3个特性
- leader选举(leader election)
- 主要涉及到3个角色:leader, follower和candidate。leader在Raft协议处于核心地方,数据是单向流动的。从leader->follower。candidate不接受leader发送的心跳。
- candidate:如果follower在规定的时间内没有收到leader的心跳,follower则认为leader已死。 该follower作为candidate,发起投票。如果接收到来自集群的大多数follower的投票,则该candidate被选举为新的leader(如下candidate被选举为leader的过程)
- 一般情况下客户端不会把请求发送到follower。 即使客户端将请求发送到follower, follower会拒绝client的请求,并把leader的ip返回给client 。
- 初始化时,所有的节点都是follower。当一个节点在规定的时间内没有收到leader的心跳,自己会转变成一个candidate,term加1。并向其他的follower发起投票。大多数的follower返回给candidate的投票,该candidate成为leader。
- follower接收leader的replication log。
- 日志复制(log replication): leader将follower执行的指令,心跳,leader的快照和配置(Cold, Cold,new)都通过replication log传递。
- 安全性(safety): 即无论何种情况(例如网络时延,丢包等情况) 最终返回client的结果是一致的。
- Raft 简述
- 通过日志的复制(传递)来实现各个机器状态(执行命令)的传递。
- 每个机器(follower)接收leader的日志(是一种'推'的方式)。日志中按顺序存储命令。每个状态机按照顺序执行日志中的命令。日志中的命令(leader从client接收的请求。leader会将请求中的内容写入日志中)
- 如下图图1所示
- Consensus Module接收从客户端发来的请求. Consensus Module会和其他机器(follower)上的Consensus Module连接, 保证其他机器接收的replication log中包含相同顺序的指令(即客户端发送给leader的执行命令)。即每个机器执行的命令顺序是一致的。
- leader从client获取执行的命令, 之后通过replication log传递给其他server(follower)。leader告诉follower replication log是否安全(即log的顺序是否有序一致).如果有序一致,则可以通过follower的State Machine(状态机)执行replication log中的内容。
- leader自己决定client 请求的内容在log中的位置,不需要和其他的follower协商。数据流的顺序是从leader到其他的follower。这个特性决定了Raft的效率要比Paxos的高。
- follower如果和leader无法连接,无法连接的follower会成为candidate(此时term + 1), 向其他的follower发起leader的选举。其他的follower会响应这个candidate发起的投票,收到大多数的投票的candidate会成为新的leader。
图1: ConsensusModule处理log的一致性
- candidate被选举为leader的过程.如下图2
图2:follower作为新的leader的过程
背景
Paxos协议晦涩难懂,在工程实践中难以得到应用。Raft是一种分布式一致算法,是RaplicationAnd Fault Tolerant的缩写。Raft相对来说容易理解,容易应用到工程实践中去。所以Raft会大行其道。
Raft协议
- Raft的协议主要包含以下3个特性
- leader选举(leader election)
- 主要涉及到3个角色:leader, follower和candidate。leader在Raft协议处于核心地方,数据是单向流动的。从leader->follower。candidate不接受leader发送的心跳。
- candidate:如果follower在规定的时间内没有收到leader的心跳,follower则认为leader已死。 该follower作为candidate,发起投票。如果接收到来自集群的大多数follower的投票,则该candidate被选举为新的leader(如下candidate被选举为leader的过程)
- 一般情况下客户端不会把请求发送到follower。 即使客户端将请求发送到follower, follower会拒绝client的请求,并把leader的ip返回给client 。
- 初始化时,所有的节点都是follower。当一个节点在规定的时间内没有收到leader的心跳,自己会转变成一个candidate,term加1。并向其他的follower发起投票。大多数的follower返回给candidate的投票,该candidate成为leader。
- follower接收leader的replication log。
- 日志复制(log replication): leader将follower执行的指令,心跳,leader的快照和配置(Cold, Cold,new)都通过replication log传递。
- 安全性(safety): 即无论何种情况(例如网络时延,丢包等情况) 最终返回client的结果是一致的。
- leader选举(leader election)
- Raft 简述
- 通过日志的复制(传递)来实现各个机器状态(执行命令)的传递。
- 每个机器(follower)接收leader的日志(是一种'推'的方式)。日志中按顺序存储命令。每个状态机按照顺序执行日志中的命令。日志中的命令(leader从client接收的请求。leader会将请求中的内容写入日志中)
- 如下图图1所示
- Consensus Module接收从客户端发来的请求. Consensus Module会和其他机器(follower)上的Consensus Module连接, 保证其他机器接收的replication log中包含相同顺序的指令(即客户端发送给leader的执行命令)。即每个机器执行的命令顺序是一致的。
- leader从client获取执行的命令, 之后通过replication log传递给其他server(follower)。leader告诉follower replication log是否安全(即log的顺序是否有序一致).如果有序一致,则可以通过follower的State Machine(状态机)执行replication log中的内容。
- leader自己决定client 请求的内容在log中的位置,不需要和其他的follower协商。数据流的顺序是从leader到其他的follower。这个特性决定了Raft的效率要比Paxos的高。
- follower如果和leader无法连接,无法连接的follower会成为candidate(此时term + 1), 向其他的follower发起leader的选举。其他的follower会响应这个candidate发起的投票,收到大多数的投票的candidate会成为新的leader。
图1: ConsensusModule处理log的一致性
- candidate被选举为leader的过程.如下图2
图2:follower作为新的leader的过程