ETCD源码分析——主要模块

超、凢脫俗 2022-09-11 00:05 241阅读 0赞

## etcd 核心模块 ##

下图中展示了 etcd 如何处理一个客户端请求涉及到的模块和流程。图中淡紫色的矩阵表示 etcd ，它包括如下几个模块：  
etcd server：对外接受客户端的请求，请求 etcd 代码中的 etcd server 目录，其中还有一个 raft.go 的模块与 etcd raft 库进行通信。etcd server 中与存储相关的模块是 applierV3，这里封装了 V3 版本的数据存储， WAL(write ahead log)，用于写数据日志，etcd 启动时会根据这部分内容进行恢复  
etcd raft：etcd 的 raft 库，前面的文章已经具体分析过这部分代码。除了与本节点的 etcd server 通信之外，还与集群中的其他 etcd server 进行交互一致性数据同步的工作（集群中其他etcd服务用橙色的椭圆表示）。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6IKl5Y-U6I-M_size_20_color_FFFFFF_t_70_g_se_x_16]  
在上图中，一个请求与一个 etcd 集群的交互主要流程分为两大部分：

*  写数据到某个 etcd server 中。
 *  该 etcd server 与集群中的其他 etcd 节点进行交互， 当确保数据已经被存储之后应答客户端。

请求流程划分为了以下几个子步骤：  
1.1：etcd server 收到客户端请求。  
1.2：etcd server 将请求发送给本模块的 raft.go，这里负责与 etcd raft 模块进行通信。  
1.3：raft.go 将数据封装成 raft 日志的形式提交给 raft 模块。  
1.4：raft 模块会首先保存到 raftLog 的 unstable 存储部分。  
1.5：raft 模块通过 raft 协议与集群中其他 etcd 节点进行交互。  
注意在以上流程中，假设这里写入数据的 etcd 是 leader 节点，因为在 raft 协议中，如果提交数据到非leader节点的话需要路由到 etcd leader 节点去。  
应答步骤如下：  
2.1 ：集群中其他节点向 leader 节点应答接收这条数据库。  
2.2：当 leader 节点收到超过半数以上应答接收这条日志数据的节点时，etcd raft 通过 Ready 结构体通知 etcd server 中的 raft 该日志数据已经 commit。  
2.3：raft.go 收到 Ready 数据时，首先将这条日志写到 WAL 模块中。  
2.4：通知最上层的 etcd server 该日志已经 commit。  
2.5：etcd server 调用 applierV3 模块将日志写入持久化存储中。  
2.6：etcd server 应答客户端该数据写入成功。  
2.7：最后 etcd server 调用 etcd raft，修改其 raftLog 模块的数据，将这条日志写入 raftLog storage 中。  
从上面的流程可以看到：

*  etcd raft 模块在应答某条日志数据已经 commit 之后，是首先写入到 WAL 模块中的，因为这个模块只是添加一条日志，所以速度很快。即使在后面 applierV3 写入失败，重启的时候也可以根据 WAL 模块中的日志数据进行恢复。
 *  etcd raft 中的 raftLog，按照前面文章的分析，其中的数据是保存到内存的，重启即失效，上层应用真实的数据是持久化保存到 WAL 和 applierV3 中的。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6IKl5Y-U6I-M_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/833afaf44f9a4384be8366ffefa92732.png