【etcd】1.etcd架构与raft算法

目录

etcd架构 

1、etcd提供的能力

2、主要模块

3、一个请求处理流程

raft一致性共识算法

1、分布式的CAP理论

2、共识机制

3、读源码

（1）主要思想

（2）预写日志

（3）etcd的读是强制读主的

（4）读请求的应用层算法层交互

---

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）读请求的应用层算法层交互

参考：

解析分布式共识算法之Raft算法_哔哩哔哩_bilibili

raft 工程化案例之 etcd 源码实现