目录
etcd架构
1、etcd提供的能力
-
kv存储
-
高可用:raft共识算法,多数派选举,数据同步(算法层raft包)
-
服务注册与发现(服务端:endpoints包,客户端:resolver包)
-
分布式锁(concurrency包)
-
集群选举
2、主要模块
3、一个请求处理流程
(1)客户端入口
-
接收grpc调用(图中1)或http调用(图中2)
-
接收集群内其他节点的消息,同步数据、心跳、选举等(图中34)
(2)api层
-
提供http、grpc访问
-
将请求推送到node层的channel队列 recvc或propc 里(图中5)
(3)node应用层
-
接收到recvc或propc事件
-
调用raft层的Step()方法,会根据当前节点状态触发实际的stepLeader()/stepFollower()/setpCandidate()
-
如果是非leader收到读写请求,会将请求转发给leader
-
如果leader节点收到写请求,分为提议/提交 两步
-
先发送预写日志的提议给raft层的readyc队列,等待提议结果
-
如果超过半数通过,触发提交,即更新状态机,并等待下次心跳时同步index
-
包含状态机(内存的),记录预写日志状态,applyIdx, commitIdx
(4)raft算法层
-
接收到readyc事件,处理数据
-
比如当前是follower,收到了一个提议请求,根据比较leader任期、日志index 判断是否要接受提议
-
比如当前是candidate,收到了一个投票请求,发现对方任期更大,就给它投一票,并退为follower
-
包含存储层(boltdb kv存储)
raft一致性共识算法
1、分布式的CAP理论
-
C 一致性:强调数据的正确性. 每次读操作,要么读到最新,要么读失失败
-
A 可用性:强调客户端的请求能够得到及时响应,不发生错误,也不等待过长
-
P 分区容错性:在不可靠的网络环境下,系统仍然是正常运作的,不出现系统崩溃或秩序混乱的局面
CAP 理论强调的是,一个系统中,C、A、P 三项性质至多只能满足其二。
首先,对于单机系统,其无须考虑 P,可以保证 CA 的满足。
其次,对于分布式系统而言, P 是必须得到保证的,否则就违背了“分布式”的语义,那么分布式系统会分为两种流派:
-
CP:强调系统数据的正确性,但由于建立保证不同节点间保证数据严格一致的机制,可能会牺牲系统的及时性(如etcd, zookeeper)
-
AP:强调系统的及时响应,那就必须在数据一致性上做出妥协退让(如redis)
2、共识机制
共识机制:是区块链中的概念,一种使区块链网络中的不同节点能够达成共识的算法或协议,旨在解决在去中心化网络中如何验证和确认交易。
raft的分布式一致性共识算法:在分布式系统中,使得所有节点对同一份数据的认知能够达成共识的算法。
-
对可用性 A:raft 算法保证当半数以上节点存活时,系统是稳定可用的,同时请求耗时取决于多数派的下限,而非所有节点的下限
-
对一致性 C:标准的 raft 算法能保证数据最终一致性,可以在 raft 算法的基础上稍加改进,保证数据的即时一致性,做到强 C
3、读源码
(1)主要思想
-
角色划分:leader/follower/candidate
-
多数派选举,预选举,心跳
-
预写日志,term,index的数据一致性保证
-
两阶段提交(propsal/commit)
(2)预写日志
WAL(write ahead log)通过日志的方式记录下每一笔写请求的明细。
leader会将写请求先组织成预写日志的形式添加到日志列表中,向其他写点同步信息,即发送一个预写日志的提议(propsal),当提议达到集群多数派的认可后,才能够被提交(commit),由leader更新到状态机当中,并且在下一次心跳时向其他节点同步这个提交。
在日志同步过程中,为了保证日志的顺序与完整性,leader会将上一笔已提交的日志索引也发送过去,如果follower对比发现不一致会拒绝这次提议。
commitIndex:已提交的日志索引,appliedIndex:已更新到状态机的日志索引
(3)etcd的读是强制读主的
任何发给非leader得读请求都会转发给leader。同时为了避免网络分区多个leader存在的情况,leader在处理读请求时会做一次自证身份,即发起一轮广播,获得多数派认可证明自己身份合法,然后才会对读请求做出响应。
非leader不会实际读写数据,会把读写请求都转发给leader
(4)读请求的应用层算法层交互
参考: