【ETCD】ETCD Leader 节点写入数据流程概览

ETCD 是一个广泛应用于分布式系统中的键值存储系统，它通过 Raft 共识算法保证数据的一致性。本文将基于提供的图片，按照编号对 ETCD Leader 节点处理写入请求的完整流程进行详细解析，帮助读者深入理解其核心工作原理。

目录

• • • • [1. 客户端发起写请求](#1. 客户端发起写请求)
      • [2. 转发请求至 Raft 子系统](#2. 转发请求至 Raft 子系统)
      • [3. Leader 节点持久化请求至本地 WAL](#3. Leader 节点持久化请求至本地 WAL)
      • [3'. 将日志转发给 Follower 节点](#3'. 将日志转发给 Follower 节点)
      • [4. Follower 节点写入 WAL](#4. Follower 节点写入 WAL)
      • [5. Follower 确认日志复制完成](#5. Follower 确认日志复制完成)
      • [6. Leader 标记事务为已提交](#6. Leader 标记事务为已提交)
      • [7. 通知 etcd-server 层应用日志](#7. 通知 etcd-server 层应用日志)
      • [8. 异步同步数据到 BoltDB](#8. 异步同步数据到 BoltDB)
      • [9. 返回客户端成功响应](#9. 返回客户端成功响应)
    • 写入流程总结

1. 客户端发起写请求

客户端通过 gRPC 接口向 ETCD 的 Leader 节点发送写请求。写请求包含目标键值对等数据。此步骤标志着写操作的起点。

2. 转发请求至 Raft 子系统

Leader 节点接收客户端的写请求后，将请求转发给 Raft 子系统。Raft 子系统负责协调日志复制和一致性，确保分布式环境下写入操作的可靠性。

3. Leader 节点持久化请求至本地 WAL

Raft 子系统在 Leader 节点上将写请求记录到本地的 Write Ahead Log（WAL）。WAL 是一项预写日志机制，确保数据写入前先记录日志，提供可靠的故障恢复能力。

3'. 将日志转发给 Follower 节点

Leader 节点向集群中的 Follower 节点广播写入日志。通过 HTTP 请求，日志被传递至每个 Follower 节点，以实现分布式复制。

4. Follower 节点写入 WAL

Follower 节点接收日志后，首先将其写入本地的 WAL 日志文件中，确保即使发生节点故障，数据也能够从日志中恢复。

5. Follower 确认日志复制完成

Follower 节点完成 WAL 日志写入后，向 Leader 节点发送确认消息。Leader 节点统计来自多数派节点的确认信息，以此判定数据已成功复制。

6. Leader 标记事务为已提交

当 Leader 节点收到多数派节点（包括自己）的确认后，Raft 算法将此事务标记为"已提交"（Committed）。此时，该事务被认为已经在集群中达成一致。

7. 通知 etcd-server 层应用日志

Leader 节点通知上层的 etcd-server 模块，将已提交的日志应用到 MVCC（多版本并发控制）存储中。MVCC 存储可以支持高效的事务操作和数据多版本管理。

8. 异步同步数据到 BoltDB

在日志被应用到 MVCC 存储后，ETCD 异步将数据同步到磁盘文件中。BoltDB 是 ETCD 使用的嵌入式存储数据库，支持高效的磁盘存储操作。BoltDB 的数据同步每隔 100 毫秒进行一次，以避免阻塞写入路径，从而提高整体性能。

9. 返回客户端成功响应

在事务被成功提交并持久化到存储后，Leader 节点通过 gRPC 向客户端返回成功响应。这标志着整个写请求处理流程的结束。

写入流程总结

通过以上分析可以看出，ETCD 的 Leader 节点写入流程涉及多个关键组件与步骤，其设计在一致性与性能之间取得了平衡：

• 一致性保障：通过 Raft 算法和 WAL 日志机制，保证数据写入的可靠性和集群一致性。
• 性能优化：通过异步的 BoltDB 写入机制和高效的 MVCC 存储，提升了整体写入效率。

这些特点使 ETCD 成为现代分布式系统中不可或缺的基础设施之一。

希望本文对您理解 ETCD 写入流程有所帮助。如有疑问或建议，欢迎留言交流！