Raft state of log
commitIndex : A log entry is committed once the leader that created the entry has replicated it on a majority of the servers.
在大多数服务器上复制了该条日志,则该条日志的index可以被认为是commited
lastApplied : 上一个被状态机应用的index
这2个属性都被标注了 volatile
Impl in Etcd
日志复制分为了2个阶段的过程,commit和apply,commit是raft状态机间相互确认日志同步的过程,apply是应用处理好相关日志并通知raft状态机已被应用的过程
apply的过程较为抽象,由应用来决定业务上需要apply的过程,实际上是应用commited的日志的应用逻辑,在完成逻辑后,只是向raft状态机标记日志被应用方处理了
Structure
主要由2个包组成,
pkg raft 是raft算法的具体实现
pkg etcdserver作为使用raft算法的应用,包含具体的应用逻辑与交互胶水
pkg raft
pkg etcdserver
remote request sequential flow
raft msg handle sequential flow
就是试试mermaid,还蛮好用的
Flow
Commit flow
proposal
follower accept proposal
leader commit proposal
除开SnapShot以及重启节点的特殊逻辑,正常启动一个Node,在Storage中实际上存储了uncommited&commited的日志,并且在启动时设置了commitedIndex就是日志的最大长度,某些极端情况下,日志会有不同,所以在Follower accept proposal的过程中,会有检测冲突的过程,以及Leader强制Follower跟随自己的日志
apply flow
每个节点都会有自己的applied index,并不需要同步。
流程见 raft msg handle sequential flow
这一步 Node(pkg raft): call ready(), collect entries from raft log & msgs needs handle ,会生成 Ready 数据,里面包含untable entries,以及 committed entries。其中Entries字段实际上是包含了 raftlog中 unstable 的日志,里面含有uncommitted&committed的日志,因为没有被标记成applied,所以是 unstable的。
Ready通过channel数据传输至 EtcdServer后,在这里应用层的逻辑就会执行,存储,应用,之后mark 日志为 applied,并且将unstable中applied的日志清除掉。
Summary
缺失了snapshot,log compact ,leader change , config change , read linear的流程。
在交互上还未去确认的地方,是否applied过后的日志才被etcd承认,按照目前的流程,其实commit过后的,虽然有可能会丢失,但也可以被承认如果是乐观看待的话。