【ETCD】当客户端从follower节点发起写请求时候,ETCD集群是如何处理此次的写请求呢?
当客户端从follower节点发起写请求时候,ETCD集群是如何处理此次的写请求呢?
目录
- 1. 客户端发起请求
- 2. Follower节点转发请求
- 3. 转发给Leader节点
- 4. Leader节点处理请求
- 4.1 写入预写日志(WAL)
- 4.2 发送复制请求
- 5. Follower节点持久化数据
- 6. Leader确认复制完成
- **7. Leader节点确认提交**
- 8. Follower节点标记为已提交
- 9. 通知etcd服务器应用提交的条目
- 10. 应用条目到MVCC存储和后端
- 11. 返回成功响应
- 总结
1. 客户端发起请求
- 功能:客户端向ETCD集群中的某个Follower节点发起写请求(通过gRPC端点)。
- 原因:客户端需要将数据写入ETCD,通常是键值对的形式。
- 作用:这是整个写入流程的起点,触发ETCD的数据一致性流程。即使请求落到Follower节点,集群内部会确保正确处理。
2. Follower节点转发请求
- 功能:Follower节点接收到请求后,将其转发至当前集群的Leader节点。
- 原因:Raft一致性协议要求,只有Leader节点可以处理写入请求,Follower节点只能处理读取请求或转发写入请求。
- 作用:确保ETCD遵循Raft协议,将写请求交由Leader处理,避免数据冲突。
3. 转发给Leader节点
- 功能:Follower节点将请求通过内部集群通信转发给Leader节点。
- 原因:Leader节点是整个Raft集群中负责写入操作的核心节点,只有Leader才能协调数据一致性。
- 作用:将客户端写请求正确路由到能处理该请求的Leader节点,避免写入失败。
4. Leader节点处理请求
4.1 写入预写日志(WAL)
- 功能:Leader节点首先将事务数据写入自己的WAL(Write Ahead Log)。
- 原因:WAL是Raft协议中关键的一环,用于保证在节点宕机时能够恢复未完成的操作。
- 作用:通过持久化事务数据,确保即使系统崩溃,数据不会丢失,满足可靠性要求。
4.2 发送复制请求
- 功能:Leader节点通过Raft协议将数据广播给其他Follower节点,请求它们将事务写入各自的WAL中。
- 原因:Raft协议需要在集群中多数节点都持久化数据后,才能认为事务成功。
- 作用:确保集群内多数节点拥有该事务的副本,从而提供容错能力。
5. Follower节点持久化数据
- 功能:Follower节点将接收到的事务数据写入自己的WAL。
- 原因:WAL是数据一致性的核心部分,所有节点都需要将事务数据持久化到WAL中。
- 作用:让Follower节点保存事务副本,为Leader确认数据复制成功提供依据。
6. Leader确认复制完成
- 功能:Leader节点等待多数(通常是集群的多数节点)Follower节点确认已将事务数据写入它们的WAL。
- 原因:Raft协议要求,只有当集群中超过半数节点持久化数据时,事务才能被标记为提交。
- 作用:通过多数节点的确认,保证数据在分布式环境中的一致性和容错能力。
7. Leader节点确认提交
- 功能:Leader节点在满足多数派原则后,将事务标记为“已提交”。
- 原因:Raft协议设计通过多数派投票机制确保数据提交安全且可靠。
- 作用:事务一旦提交,集群中的所有节点都必须最终应用该事务,防止数据丢失。
8. Follower节点标记为已提交
- 功能:Leader节点将提交信息广播给Follower节点,Follower节点将事务标记为“已提交”。
- 原因:确保集群中的所有节点都知道该事务已经成功提交。
- 作用:Follower节点同步事务状态,为之后应用事务到实际存储打下基础。
9. 通知etcd服务器应用提交的条目
- 功能:Leader节点通知etcd服务器将已提交的事务应用到MVCC存储和后端。
- 原因:WAL仅保证事务持久化,数据最终需要应用到存储引擎才能对外生效。
- 作用:将已提交的事务应用到实际存储,完成对数据的更新。
10. 应用条目到MVCC存储和后端
- 功能:etcd服务器将事务数据应用到MVCC存储,并异步同步到BoltDB文件。
- MVCC存储:多版本并发控制存储,支持高效的并发读写。
- BoltDB文件:将MVCC存储中的数据异步写入磁盘,确保持久化。
- 原因:MVCC存储提供高性能的读写能力,BoltDB则提供数据的最终持久化保障。
- 作用:完成整个写入操作,同时通过异步方式提升性能,避免阻塞写入路径。
11. 返回成功响应
- 功能:etcd服务器返回成功的gRPC响应给客户端,通知写操作完成。
- 原因:让客户端知道写入已经成功提交到集群,保证操作的可观测性。
- 作用:为客户端提供可靠的反馈,标志整个写入流程的结束。
总结
这个过程展现了ETCD在分布式环境中处理写请求的完整流程:
- 通过Raft协议实现一致性和容错能力。
- 利用WAL和MVCC存储实现高性能和高可靠性。
- 异步持久化进一步提高写入效率。
这种设计确保ETCD既能满足高可用性的要求,也能在分布式环境中提供一致性和可靠性。