etcd资料汇总

使用场景

• etcd 的场景默认处理的数据都是系统中的控制数据。所以etcd在系统中的角色不是其他NoSQL产品的替代品，更不能作为应用的主要数据存储。etcd中应该尽量只存储系统中服务的配置信息，对于应用数据只推荐把数据量很小，但是更新和访问频次都很高的数据存储在etcd中。
• 服务发现
• 配置中心

etcd的核心组件

image.png

• HTTP Server：用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。

• Store：用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。

• https://etcd.io/docs/v3.5/learning/img/data-model-figure-01.png
  

  image.png

• Raft：Raft 强一致性算法的具体实现，是 etcd 的核心。

  
  image.png

• WAL：Write Ahead Log（预写式日志），是 etcd 的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储。WAL 中，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。

• 用户请求流程

• 通常，一个用户的请求发送过来，会经由 HTTP Server 转发给 Store 进行具体的事务处理，如果涉及到节点的修改，则交给 Raft 模块进行状态的变更、日志的记录，然后再同步给别的 etcd 节点以确认数据提交，最后进行数据的提交，再次同步。

用户从集群中哪个节点读写数据？

• 为了保证数据的强一致性，etcd集群中所有的数据流向都是一个方向，从 Leader （主节点）流向 Follower，也就是所有 Follower 的数据必须与 Leader 保持一致，如果不一致会被覆盖。

• 简单点说就是，用户可以对etcd集群中的所有节点进行读写，读取非常简单因为每个节点保存的数据是强一致的。对于写入来说，etcd集群中的节点会选举出Leader节点，如果写入请求来自Leader节点即可直接写入然后Leader节点会把写入分发给所有Follower，如果写入请求来自其他Follower节点那么写入请求会给转发给Leader节点，由Leader节点写入之后再分发给集群上的所有其他节点。

1. 只有leader节点能进行更新操作
2. 当接收到数据更新的请求时，当前节点若是follower将会把信息转发给leader节点
3. 然后通过两阶段提交
    1. leader节点首先发送给其他follower节点日志包，说我要更新数据。
    2. follower节点收到日志包后，会告诉主节点说准备就绪
    3. leader节点收到回复后会下commit命令，然后所有节点统一更，并返回客户端相应成功

• 读流程

  
  image.png

• 写流程

  
  image.png

如何选举Leader节点

• Raft 选举

判断写入是否成功（写入节点>=Quorum(法定人数) = N/2+1

• etcd认为写入请求被Leader节点处理并分发给了多数节点后，就是一个成功的写入。如何界定多数节点呢？很简单，假设总结点数是N，那么多数节点 Majority=N/2+1，不过在etcd中使用的术语是 Quorum而不是 Majority。所以界定多数节点的公式是 Quorum=N/2+1。

etcd CAP选择

• CP

ref

• 看图轻松了解etcd
• https://blog.csdn.net/m0_38004619/article/details/115110166
• https://cloud.tencent.com/developer/article/1532452
• https://www.bilibili.com/video/BV1Q84y167hF?p=3&vd_source=82e03147a3c338ea1383309670651595