etcd学习笔记

本文为极客时间《etcd实战课》的学习笔记

etcd在你的理解中它分为哪几层

client网络层：client层包括v2和v3两个api库,提供了简洁易用的 API，同时支持负载均衡、节点间故障自动转移，可极大降低业务使用 etcd 复杂度，提升开发效率、服务可用性。

api层：API 网络层主要包括 client 访问 server 和 server 节点之间的通信协议。

raft算法层：Raft 算法层实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性，用于保障 etcd 多个节点间的数据一致性、提升服务可用性等

功能逻辑层：etcd 核心特性实现层，如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等，其中 MVCC 模块主要由 treeIndex 模块和 boltdb 模块组成。

存储层：存储层包含预写日志 (WAL) 模块、快照 (Snapshot) 模块、boltdb 模块。其中 WAL 可保障 etcd crash 后数据不丢失，boltdb 则保存了集群元数据和用户写入的数据。

etcd的一个读请求是怎样完成的？
client 会向endpoint发送 Range RPC 请求到了 server，然后会进入拦截器，拦截器提供执行一个请求前后的hook的能力，可以实现日志，metrics统计，请求行为检查等等的功能。然后进入etcd的key-V Server模块，KVServer 模块收到线性读请求后，通过架构图中流程三向 Raft 模块发起 ReadIndex 请求，Raft 模块将 Leader 最新的已提交日志索引封装在流程四的 ReadState 结构体，通过 channel 层层返回给线性读模块，线性读模块等待本节点状态机追赶上 Leader 进度，追赶完成后，就通知 KVServer 模块，进行架构图中流程五，与状态机中的 MVCC 模块进行进行交互了。

etcd的一个写请求是怎样完成的？

etcd的MVCC机制是怎么实现的？

etcd的watch机制

etcd的事务的实现机制
etcd中的事务实现和mysql不一样，etcd的事务api由 if than else三种语句实现，它的基本原理是，如果 if 语句的条件判断成功，那么就执行 than 中的 Put, Get Delete等等的操作，否则执行else里面的操作。在if语句中，支持的检查项有，key 的最近一次修改版本号 mod_revision， key 的创建版本号 create_revision，key 的修改次数 version。 key 的 value 值。

基于raft实现的etcd数据可能出现数据不一致吗，为什么

etcd请求出现延时的原因
etcdserver: request timed out
etcd适合读多写少的应用场景，一般出现延迟，可能是网络，磁盘，或者某个请求慢的原因。

网络：在etcd的读写流程里面，leader节点发送信息给其他节点，依赖网络的性能，在etcd中，各个节点之间的通信是使用2380端口通信，来完成leader选举，日志同步等等的功能，因此底层网络的性能，会影响etcd的请求延时，我们可以使用常规的网络工具去定位是否是网络的瓶颈，同时，etcd应用层也提供了很多的metrics指标来观察是否是网络的原因导致的延时。

etcd_network_active_peer，表示 peer 之间活跃的连接数；etcd_network_peer_round_trip_time_seconds，表示 peer 之间 RTT 延时；
etcd_network_peer_sent_failures_total，表示发送给 peer 的失败消息数；
etcd_network_client_grpc_sent_bytes_total，表示 server 发送给 client 的总字节数，通过这个指标我们可以监控 etcd 出流量；
etcd_network_client_grpc_received_bytes_total，表示server 收到 client 发送的总字节数，通过这个指标可监控 etcd 入流量。

磁盘：磁盘的性能也可能是etcd请求延时的原因，因为在写入日志条目到WAL的时候，依赖磁盘的写性能。我们可以关注磁盘的指标，以及在etcd应用层也有 metrics(etcd_disk_wal_fsync_duration_seconds 和 etcd_disk_backend_commit_duration_seconds) 来观测应用层数据写入磁盘的性能。

expensive request:除此之外，还可能是因为有一些请求比较耗时导致的，对于一些耗时的请求，默认会在 etcd log 中打印一条"apply request took too long"的警告日志。通过此日志我们可以知道集群中 apply 流程产生了较慢的请求，但是不能确定具体是什么因素导致的。比如在 Kubernetes 中，当集群 Pod 较多的时候，若你频繁执行 List Pod，可能会导致 etcd 出现大量的"apply request took too long"警告日志。