raft小记

• RequestVote RPC 由candidate在选举（elections）期间发起，以获取投票（5.2 section）
• AppendEntries RPC 由 leader 发起以复制日志条目请求，并提供一种心跳形式（5.3 section）。如果服务没有及时收到响应，它们会重试 RPC，并且并行发出 。
• 在任意服务器中，只要写入了的日志，一定是已经完成的日志；或只有leader能新增条目（？）
• 如果不同服务器日志中的两个条目具有相同的索引和任期，则它们存储相同的命令。
• 如果不同服务器日志中的两个条目具有相同的索引和任期，则该日志在所有前面的条目中都是相同的。
• 在 Raft 中 leader 通过强制 follower 的日志复制自己 (leader) 的日志来处理不一致
• leader 为每个 follower 维护一个 nextIndex， leader 第一次上任时，它将所有 nextIndex 值初始化为其日志中最后一个之后的索引。即leader上任后保证集群所有机器日志条目与自己相同，否则更新follower的条目
• leader 永远不会覆盖或删除自己日志中的条目
• 仅日志包含所有已提交的条目的candidate可以胜出选举；RequestVote RPC 实现了这个限制：RPC 包含有关 candidate 日志的信息，如果选民自己的日志比候选人的日志更新，则选民拒绝投票。（若包含有拜占庭错误，此处可导致不一致）
• 最新指：term较晚或日志更长
• Raft 从不通过计算副本数来提交之前任期的日志条目，仅提交来自 leader 当前任期的日志条目（也就是说，follower以前term的日志不会被leader覆盖）
• 最终结果：在不含拜占庭问题的情况下，1. leader一定包含所有已经提交的日志条目 2. 集群中条目不完整的candidate，不能获得选票从而成为leader 3.由1,2递推到leader应包含所有已提交的日志条目（？）
• broadcastTime≪electionTimeout≪MTBF
• 配置更改使用两阶段方法来防止脑裂，增加C(old,new)阶段There is no point in time in which Cold and Cnew can both make decisions independently
• 服务器在当前 leader 的最小选举超时时间内收到 RequestVote RPC，不会更新任期或授予投票，以防止离线的集群发送的RV RPC干扰集群运行
• Raft中的每个服务器都独立地对本地已提交的日志进行压缩，并覆盖原先日志的位置。由AppendEntries API的一致性检查保证正确。
• 客户端为每个命令分配唯一的序列号，向leader请求时，附带序列号。解决leader提交日志之后，响应客户端之前崩溃导致操作不幂等的问题。
• 解决client只读请求发送到old leader问题1. Raft每个领导者在术语开始时向日志中提交一个空白的no-op条目。 2. 在处理只读请求之前，领导人必须检查自己是否已被罢免。