基于Raft算法设计分布式一致性存储的工程实践的需求分析和概念原型
工程项目实践---基于Raft算法设计分布式一致性存储
一、RAFT需求分析和项目概述
Raft是一种共识算法，旨在替代Paxos。 通过逻辑分离比， Raft提供了一种在计算系统集群中分布状态机的通用方法，确保集群中的每个节点都同意一系列相同的状态转换。
raft通过领导方法实现共识。该服务器集群只有一个当选的领导者，负责管理集群其他服务器上的日志复制。这意味着领导者可以决定新条目的放置和在其与其他服务器之间建立数据流而无需咨询其他服务器。领导者领导，直到失败或断开连接，在这种情况下，新的领导者当选。集群上的所有节点有三种状态：Follower,Candidate,Leader,所有节点主机的状态不是一直不变的，是动态变化的
二、项目用例图建模
三、业务类图
业务类图建模的具体步骤如下
- 收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料。
- 头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系。
- 给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
- 将结果用 UML 类图画出来。
RAFT算法项目的主要业务类包括：
所有服务器节点的类都基本一致。节点的运行主要根据当前服务器的状态来节点调用的业务类和业务办法。
1、Leader状态下的类和方法
2、Follower状态下的类和方法
3、Candidate的类和方法，除了func runCandidate外，和Follower基本一致，下面不再给出，
4、labrpc.ClientEnd是当前Leader服务器调用远程Follower服务器的RPC的去运行AppendEntries接收心跳或者日志的包，过于繁杂，不再给出。
四、业务数据模型（就是数据库的关系关联表）
本项目算法就是为了实现KV存储实现数据库的更新的一致性，所以不用建立数据库的表
五、概念模型和工作流程
RAFT算法主要分三个阶段:
选举阶段一：
Raft 使用心跳（heartbeat）触发Leader选举。当服务器启动时，初始化为Follower。Leader向所有Followers周期性发送heartbeat。如果Follower在选举超时时间内没有收到Leader的heartbeat，就会等待一段随机的时间后发起一次Leader选举。顺序如下：
1、A、B主机向C主机投票请求，A先到达，C同意A成为领导，那么A投的是自己的一票，A成为领导，A向B C主机发送心跳。
2、B收到A的领导的心跳，，表示有其它服务器成为Leader，,从Candidate状态退成Follower者。
3、如果选举阶段，没有服务器赢得多数的投票，等待选举超时，继续下一轮选举。
正常工作阶段二（日志发送和日志同步）：
Leader的工作：Leader选出后，就开始接收客户端的请求。Leader把请求作为日志条目（Log entries）加入到它的日志中，然后并行的向其他服务器发起 AppendEntries RPC，复制日志条目。当这条日志被复制到大多数服务器上，Leader将这条日志应用到它的状态机并向客户端返回执行结果。
某些Followers可能没有成功的复制日志，Leader会无限的重试 AppendEntries RPC直到所有的Followers最终存储了所有的日志条目。
日志同步保证如下两点：如果不同日志中的两个条目有着相同的索引和任期号，则它们所存储的命令是相同的。如果不同日志中的两个条目有着相同的索引和任期号，则它们之前的所有条目都是完全一样的。
Follower的工作:接收领导的心跳，保持Follower状态
出现故障以及故障恢复阶段三：
1、出现Candidate请求的做领导的任期Term不一样的情况。此时选择最新的请求的Term最新的那一个Candidate节点服务器做领导。
2、出现出现Candidate请求的做领导的任期Term一样而且到达时间一模一样，就选择具有最新的日志的记录的Candidate做领导
3、就是部分Follower节点的对在某一个顺序上的日志的任期的和其他节点顺序上的不一样，可能还收到了上一任任期的领导节点的日志，出现了错误。那么新任期的领导者需要再次日志给所有节点去重新对客户端发来的请求，再做一次一致性的日志完成再返回客户
六、总结:
经过这次作业对于RAFT算法保证数据库一致性的需求分析和概念模型的建立，让我清晰的了解到了。一个项目的从逻辑图的建立，就是从业务用例图的建模，再到业务类图的建模，就是具体的数据结构的类的建立和对应的方法和函数，再到整个项目流程的流转的具体过程。
浙公网安备 33010602011771号