关于Raft的学习记录。如有疑问欢迎指正，也欢迎讨论。

paxos的思想理解起来很困难，只是简单地理解了一下，连着看了几天都不能真正理解，跳过先看《In Search of an Understandable Consensus Algorithm》。

个人感觉学习这两个算法就不要想着 10 分钟学会的那种文章了，越长越好，毕竟论文 18 页？

#摘要

Raft是一个共识算法，为了解决paxos难以理解的问题，解决方式是将一些共识算法中的一些概念分离，并通过safety来约束这些之间的关系。具体有四个方面，leader election、log replication、safety和membership changes。

#Raft

raft 通过选举出一位 leader 来实现共识，所有的日志复制和管理都由 leader 来全权负责。

leader 的工作内容：

接收来自客户端的指令，并将其复制给其他的服务器（Followers）。
告诉这些服务器什么时候可以应用（提交）这些指令到状态机。

#Raft basics

一个Raft集群由多台服务器组成，5 台机器的集群允许 2 台机器 down 掉（另外 3 个可以满足大多数这个需求。为了在任意时刻可以达成大多数，分布式的集群几乎都是奇数个，在不考虑机器宕机的前提下）。
任意时刻，每个服务器只拥有以下状态之一的状态：领导人（leader），追随者（follower），候选者（candidate）。

追随者：对领导人和候选者的请求作出回应。
领导人：接收所有来自客户端的请求（如果客户端请求了一个追随者，该请求会被重定向给领导人）。

关系转换

Raft 系统中的时间由任意长度的任期组成，任期以连续的整数标识。每个任期都从选举开始。

Raft 保证同一个任期内只会产生一个领导人（赢得大多数选票？），但是可能会因为选票分散而不产生领导人，系统就会进入一个新的任期，产生新一次选举。

任期在 Raft 系统中充当逻辑时钟，可以被用来检测过期信息。每台机器记录当前任期号，且设计保证任期号一直单调递增。

机器之间交流会同步任期号，如果发现自身存储的机器号较小，会用大的任期号替换本地任期号。
如果候选者或领导人发现它们还在旧的任期内（当前存储的任期号比别的机器小），会转变为追随者。
如果一个机器接收到带着旧任期号的请求，拒绝请求。

机器之间通过 rpc 进行交互。请求投票 rpc由候选人在选举期间发起。追加日志 rpc由领导人发起，用于复制日志和发送心跳。快照复制 rpc用于传输快照。机器会对没有及时响应的 rpc 进行重试^[1]，并通过并发请求的方式提升性能。

#Leader election

Raft 利用心跳机制来触发领导人选举。机器启动时初始角色为追随者。

#参考链接

那么上面拒绝请求的场景，应该如何提供数据返回呢？ ↩︎

Raft学习笔记

Contents

#摘要

#Raft

#Raft basics

#Leader election

#参考链接