Etcd基础笔记

etcd 以一致和容错的方式存储元数据。分布式系统使用 etcd 作为一致性键值存储,用于配置管理,服务发现和协调分布式工作。etcd 内部采用 raft 协议作为一致性算法,etcd 基于 Go 语言实现。

名字来源:etc 即 linux 的/etc 目录,意为存放配置文件,d 为 distributed 即分布式

etcd 的特点

  • 安装配置简单,且提供了 HTTP API 进行交互
  • 支持 SSL 证书验证
  • 单实例支持每秒 2k+读操作
  • 采用 raft 算法,实现分布式系统数据的可用性和一致性

分布式系统中的数据分为控制数据和应用数据,使用 etcd 的场景默认处理的数据都是控制数据,对于应用数据,只推荐数据量很小,但是更新访问频繁的情况

常见术语:

  • NodeRaft 状态机实例
  • Memberetcd 实例。它管理着一个 Node,并且可以为客户端请求提供服务。
  • Cluster:由多个 Member 构成可以协同工作的etcd 集群
  • Peer:对同一个 etcd 集群中另外一个 Member的称呼。
  • Client:向 etcd 集群发送 HTTP 请求的客户端。
  • Proxy:etcd 的一种模式,为 etcd 集群提供反向代理服务
  • Leader:Raft 算法中通过竞选而产生的处理所有数据提交的节点
  • Follower:竞选失败的节点作为Raft 中的从属节点,为算法提供强一致性保证。
  • Candidate:当Follower 超过一定时间接收不到 Leader 的心跳时转变为 Candidate 开始竞选
  • Term某个节点成为 Leader 到下一次竞选时间,称为一个 Term。
  • Index:数据项编号。Raft 中通过 Term 和 Index 来定位数据

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

  • 读:由于集群所有节点数据是强一致性的,可以从集群中随便哪个节点进行读取数据
  • 写:etcd 集群有 leader,可以直接往 leader 写入,然后 Leader 节点会把写入分发给所有 Follower,如果往 follower 写入,则 Leader 节点会把写入分发给所有 Follower

etcd 数据模型

etcd 架构

  • HTTP Server:用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。
  • Store:用于处理 etcd 支持的各类功能的事务,包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等,是 etcd 对用户提供的大多数 API 功能的具体实现。
  • Raft:Raft 强一致性算法的具体实现,是 etcd 的核心。
  • WAL预写式日志,etcd 用于持久化存储的日志格式。除了在内存中存有所有数据的状态以及节点的索引以外,etcd 就通过 WAL 进行持久化存储。WAL 中,所有的数据提交前都会事先记录日志。
    • Snapshot:etcd防止 WAL 文件过多而设置的快照,存储 etcd 数据状态。
    • Entry:存储的具体日志内容。

应用场景

服务注册和发现

提供服务发现功能的关键设计:

  • 强一致性、高可用的服务存储目录
  • 注册服务和监控服务健康状态的机制
  • 查找和连接服务的机制

常见服务发现形式:

  • 前后端业务注册发现:中间件和后端服务在 etcd 中注册后,前端和中间件可以从 etcd 中找到相应服务器并根据调用关系进行绑定
  • 多组后端服务器注册发现:后端多个状态相同 APP 可同时注册到 etcd 中,前端可通过 HAProxy 从 etcd 获取到后端 IP 和端口然后请求转发,能够通过动态的配置域名解析实现实例故障重启透明化

消息发布与订阅

在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅,即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。

负载均衡

分布式通知与协调

分布式锁

分布式队列

集群监控与 Leader 竞选

etcd 与 zookeeper 的区别

参考文章:

Etcd 集群搭建

Etcd 使用入门

万字长文:etcd 从入门到放弃

etcd 官方文档中文版

etcd:从应用场景到实现原理的全方位解读