Raft学习笔记

引入背景

系统瓶颈两个方向：1.增加系统配置（性价比降低）2.增加机器
纵向分布式：多个模块rpc调用。
横向分布式：一个模块多个节点，本次关注的是横向分布式
优势：1.数据备份：避免单点故障导致数据丢失或者服务不可用
2.负载均衡：多个节点分担总任务
问题：如何保证数据一致性，如何保证分布式系统的秩序。根本问题在于网络的不确定性

基础理论

CAP理论

c:consisten，一致性，每次读都读到最新活失败，写操作对于集群就像作用与单机一样
a:availablity,可用性，请求能够得到相应，不发生错误，不能出现过长的等待
p:partition tolerance，分区容错性，在网络不可靠背景下，系统正常运行，不出现系统崩溃活秩序混乱
CAP理论强调的是，一个系统中，CAP三个性质至多只能满足其二，不能全部满足。

满足A（只要主节点完成立刻返回）不满足C的问题：
1.即时一致性，一写一读，不实时同步就会不一致
2.顺序一致性，从节点先执行了后一条的同步
满足C不满足A的问题：
一个follow失败会阻塞，一个follow或者网络出现问题会导致整个系统不可用

多数派原则

多数派：超过小团体数量半数以上
多数派原则：议题超过一半以上的成员同意就通过（所以奉行多数派原则的集群一般都采用奇数个）
多数派不要求所有节点都健康，提升了A（可用性）

一主多从、读写分离

一主多从：分为leader和follower，leader负责总览全局和事务推进，follower职责是投票和执行
读写分离：读操作可以由集群任意节点提供，写操作由leader处理，向follower同步，如果follower收到写请求，也转发给leader进行处理，两个问题：
1.读操作由任意节点提供，如果是一个数据状态滞后的follower，那么客户端就可能读到老数据，即目前为止只能满足最终一致性
2.集群一主多从，若leader出现问题，需要选举机制

状态机和预写日志

状态机：节点实际存储数据的容器，读取也是在里面读取
预写日志：通过日志记录写请求明细，变更历史有迹可循。当一个日志（写请求）达到集群多数派认可后，才能被提交，将变更应用到状态机。
预写日志由一个数组承载，为一段时间多个写请求提供一个缓冲区；只要能保证预写日志数组中，被准许应用到状态机的部分每笔预写日志内容相同，就能解决乱序问题，达到数据最终一致性

两阶段提交

1.提议：leader写预写日志，和所有节点交互，把日志（或日志索引）给follower，follower做校验然后返回
2.提交：得到多数派认可后就执行提交动作（日志应用是同步或异步）

角色和切换

领导者选举

leader是写请求的入口，如果出了问题，会导致集群不可写，就需要raft的选举机制
1）follower如何感知leader挂了
leader需要定期向follower发送心跳，follower会建立心跳检测定时器，超时未收到心跳，则认为leader已死，会切换成候选人竞选，尝试成为新的leader
2.什么样的follower有资格称为leader
数据足够新且赞同票节点数达到多数派

任期和日志索引

任期会随着leader切换增加
通过任期和index唯一确定预写日志

raft的角色流转

集群刚启动都是follower，检测leader超时就会开始竞选，称为候选人，和除自己外所有节点交互，统计其他节点对自己的认同，超过半数就成为leader，超过半数的否决票就重新成为follower(或有新leader了（任期更大），或超时)

领导者

1.周期性发送心跳
2.主持两阶段提交

follower

1.写请求反馈
2.接收leader心跳获取携带的commitindex，及时完成已被多数派认可的预写日志提交
3.候选人投票
4.负责关注leader心跳来发起候选人的竞选

候选人

1.如果follower切换为candidate，会将当前任期加一作为竞选任期
2.会将自身的一票投给自己
3.广播给所有节点拉票
4.拉票超时前得到多数派认可就称为leader
5.拉票超时前遭到多数派拒绝就退回follower
6.超时前收到了任期大于等于自身任期的leader的请求，退回follower
7.拉票请求超时，竞选任期加一，发起新一轮竞选拉票请求

流程梳理

流程

写操作由leader统一处理，如果follower收到写请求也会给leader。leader添加预写日志到日志数组末尾，往follower同步，follower会判断leader合法性（像任期term），判断接不接受预写日志（上一次预写日志的{term,index}看看和自己的上一次是不是一致)，follower如果接收会写到自己的预写日志，不接受会把原因返回给leader（任期滞后：告诉leader把最新任期给leader，leader退位；follower日志滞后：会先让leader补齐日志,递归的尝试向follower同步预写日志数组中的前一笔日志，直到补齐缺失日志，流程回到正常的轨道;follower日志超前：follower移除超前的这部分日志，然后同步leader传送的日志，向当前在任的leader看齐）

最终一致性如何变为即时一致性？
1.对于leader在给到客户端之前就要在预写日志列表不仅实现了commitIndex变化，也要应用后更新applyIndex完成
2.客户读流程每次只读leader（可能网络分区错误，解决方案是在提供读服务时需要额外向集群所有节点发起广播，得到多数派认可，证明自己身份合法，才会对读请求进行响应）或者leader应用完后把applyindex返回给客户端，客户端读取时候会带上applyindex，follower会和自身的applyindex比较，如果不够新会给其他节点处理

raft算法下的内部链路请求梳理

1.日志同步请求（提议阶段）
leader在收到客户端写请求后会包装成预写日志给其他节点
接收的节点类型：leader:接到后看任期是否比自己的大，是的话代表自己的滞后，自己退位，然后走follower流程，如果比自己的小就会拒绝并返回；follower:校验leader任期是否比follwer任期，比自己大就校验上一笔日志的标识缺失就补齐，小的话就返回错误；candidate：看任期是否比自己大，大的话自己变为follower走后面流程。
请求参数，任期，leader节点id，leadercommit（leader最新提交日志的index,当前同步日志的前一条日志的index,前一条日志的term，log
响应参数：节点当前任期，是否成功，错误类型
leader后处理：多数派完成了日志同步，leader会提交这个日志

心跳 && 提交请求

leader开启一个定时器，周期性发送心跳证明自己还健在；同步日志的提交的进度
参数：term（任期）,节点id,最新提交的日志index

竞选拉票请求

候选人向集群中其他节点进行广播;leader收到后比较term是否比自己当前的大，不是的话就拒绝且返回错误信息，否则的话就变成follower;follower收到后比较term是否比自己大，是的话就校验是否投过票了本次，校验对方数据是否够新，然后投票；candidate:判断任期，比自己大就同意，小的话就拒绝
请求参数：term,candidationid,lastLogIndex,lastLogTerm

radt算法下的集群变更

1.配置变更请求由leader统一收口处理
2.leader发起提议将配置变更日志广播给所有节点，将配置变更的明显参数，能明确表示那些节点是老节点，那些是新的节点
3.当配置变更提议被老节点多数派认可时，leader才会提交配置变更动作
4.在配置变更期间，leader选举时要老节点多数派赞同票才能当选
5.在配置变更期间，写请求需要获取老节点多数派认可才能提交