etcd基础

分布式系统中最关键数据的分布式，可靠的键值存储
用于提供可靠的分布式键值存储，配置共享和服务发现等功能
默认处理数据都是控制数据，对于应用数，只推荐数据量很小，但更新访问频繁的情况，常见etcd使用场景：服务发现，分布式锁，分布式队列，分布式通知和协调，主备选举等

为什么使用etcd

与 ZooKeeper 相比，etcd更简单，安 装、部署和使用更加容易，并且 etcd 的某些功能是 ZooKeeper 所没有的,比如：

• etcd 更加稳定可靠，它的唯一目标就是把分布式一致性 KV 存储做到极致，所以它更注重稳定性和扩展性
• 在服务发现的实现上，etcd 使用的是节点租约(Lease)，并且支持Group(多 key)而 ZooKeeper 使用的是临时节点，临时节点存在很多问题
• etcd 支持稳定的 watch ，而不是 ZooKeeper 一样简单的单次触发式watch，很多调度系统需要得到完整节点历史记录(因为一个服务随时可能会下线，也可能为应对临时访问压力而增加新的服务节点)，etcd 可以存储数十万个历史变更
• etcd 支持 MVCC(多版本并发控制)，因为有协同系统需要无锁操作
• etcd 支持更大的数据规模 ， 支持存储百万到千万级别的 key
• 与ZooKeeper相比，etcd 的性能更好 。 在一个由 3 台 8 核节点组成的云服务器上， etcd v3版本可以做到每秒数万次的写操作和数十万次的读操作

etcd架构

• Client 层：Client 层包括 client v2 和 v3 两个大版本 API 客户端库，提供了简洁易用的 API，同时支持负载均衡、节点间故障自动转移，可极大降低业务使用 etcd 复杂度，提升开发效率、服务可用性
• API 网络层：API 网络层主要包括 client 访问 server 和 server 节点之间的通信协议。一方面，client 访问 etcd server 的 API 分为 v2 和 v3 两个大版本。v2 API 使用 HTTP/1.x 协议，v3 API 使用 gRPC 协议。同时 v3 通过 etcd grpc-gateway 组件也支持 HTTP/1.x 协议，便于各种语言的服务调用。另一方面，server 之间通信协议，是指节点间通过 Raft 算法实现数据复制和 Leader 选举等功能时使用的 HTTP 协议
• Raft 算法层：Raft 算法层实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性，用于保障 etcd 多个节点间的数据一致性、提升服务可用性等，是 etcd 的基石和亮点
• 功能逻辑层：etcd 核心特性实现层，如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等，其中 MVCC 模块主要由 treeIndex 模块和 boltdb 模块组成
• 存储层：存储层包含预写日志 (WAL) 模块、快照 (Snapshot) 模块、boltdb 模块。其中 WAL 可保障 etcd crash 后数据不丢失，boltdb 则保存了集群元数据和用户写入的数据

单实例etcd部署

# 下载etcd
wget https://github.com/etcd-io/etcd/releases/download/v3.5.21/etcd-v3.5.21-linux-amd64.tar.gz# 解压etcd到指定目录
tar -zxvf etcd-v3.5.21-linux-amd64.tar.gz -C /# 查看etcd版本
./etcd --version# 全局部署etcd和etcdctl
cp etcd etcdctl /usr/local/bin# 前台启动etcd服务
./etcd

# 后台启动etcd，重定向日志输出
nohup ./etcd >/tmp/etcd.log 2&1 &

# 插入键值对
etcdctl put name fox# 根据键获取键值对
etcdctl get name

etcdctl get name --endpoints=localhost:2380

指定了 etcd 集群的访问地址
etcd 实例通常会监听一个端口来接收客户端的连接
localhost 表示运行命令的本地机器，2380 是 etcd 客户端监听端口
如果不指定这个选项，etcdctl 会尝试使用默认的配置来连接 etcd 集群，如果默认配置不正确，就可能导致连接失败
通过指定 endpoints，可以明确告诉 etcdctl 要连接的 etcd 实例的地址


启动的etcd进程默认在2379端口监听客户端请求

单机多实例etcd部署

etcd server 默认使用2380端口监听集群中其他server请求
同一台机器上多个etcd server都在同一端口上监听，会导致端口冲突
分别让多个server监听各自指定的端口号

# 下载进程管理工具，快速创建，停止本地的多节点etcd集群
go install github.com/mattn/goreman@latest# 可以尝试配置代理服务器
go env -w GOPROXY=https://mirrors.aliyun.com/goproxy/,direct

需要在/etc/profile中配置GOPATH才能全局使用goreman命令

# 查询go的环境配置
go envexport GOPATH= 自己的实际路径

配置3个节点的Profile文件
–name 节点名
–listen-client-urls 监听客户端地址
–initial-cluster 集群通讯端口

原文本

etcd1: bin/etcd --name infra1 --listen-client-urls http://127.0.0.1:2379 --advertise-client-urls http://127.0.0.1:2379 --listen-peer-urls http://127.0.0.1:12380 --initial-advertise-peer-urls http://127.0.0.1:12380 --initial-cluster-token etcd-cluster-1 --initial-cluster 'infra1=http://127.0.0.1:12380,infra2=http://127.0.0.1:22380,infra3=http://127.0.0.1:32380' --initial-cluster-state new --enable-pprof --logger=zap --log-outputs=stderretcd2: bin/etcd --name infra2 --listen-client-urls http://127.0.0.1:22379 --advertise-client-urls http://127.0.0.1:22379 --listen-peer-urls http://127.0.0.1:22380 --initial-advertise-peer-urls http://127.0.0.1:22380 --initial-cluster-token etcd-cluster-1 --initial-cluster 'infra1=http://127.0.0.1:12380,infra2=http://127.0.0.1:22380,infra3=http://127.0.0.1:32380' --initial-cluster-state new --enable-pprof --logger=zap --log-outputs=stderretcd3: bin/etcd --name infra3 --listen-client-urls http://127.0.0.1:32379 --advertise-client-urls http://127.0.0.1:32379 --listen-peer-urls http://127.0.0.1:32380 --initial-advertise-peer-urls http://127.0.0.1:32380 --initial-cluster-token etcd-cluster-1 --initial-cluster 'infra1=http://127.0.0.1:12380,infra2=http://127.0.0.1:22380,infra3=http://127.0.0.1:32380' --initial-cluster-state new --enable-pprof --logger=zap --log-outputs=stderr

# 运行文件
goreman -f Profile start

# 输出集群的成员列表
etcdctl --write-out=table --endpoints=localhost:22379 member list

# 关闭集群中指定节点，其他节点仍然可以监听
goreman run stop etcd2

# 重启集群中指定节点
goreman run restart etcd2

# 向集群中写入数据
etcdctl put name fox --endpoints=localhost:22379

# 数据会在集群中同步
etcdctl get name --endpoints=localhost:32379

多节点集群部署

为了整个集群的高可用，etcd通常会以集群的方式部署，以避免单点故障
构建高可用集群：

• 静态配置
  预先已知 etcd 集群中有哪些节点，在启动时通过 --initial-cluster 参数直接指定好 etcd 的各个节点地址
• etcd 动态发现
  静态配置前提是搭建集群之前已经提前知道各节点的信息，而实际应用中可能存在预先并不知道各节点 IP 的情况，这时可通过已经搭建的 etcd 来辅助搭建新的 etcd 集群。通过已有的 etcd 集群作为数据交互点，然后在扩展新的集群时，实现通过已有集群进行服务发现的机制。比如官方提供的：discovery.etcd.io
• DNS 动态发现
  通过 DNS 查询方式获取其他节点地址信息

etcdctl命令

# 查看命令
etcdctl -h

# 创建或更新键值对
etcdctl put

# 以16进制格式返回
etcdctl get /name --hex

# 左闭右开获得范围内的键值对
etcdctl get 

# 根据前缀查询
etcdctl get --prefix /name

# 指定查询数量
etcdctl get --prefix /name --limit 2

# 读取字典顺序大于或等于指定键的键值对
etcdctl get --from-key /name2

# 通过读取一个key获取当前etcd服务端的版本号，key存不存在都可
etcdctl get /name -w=json

• cluster_id：请求的 etcd 集群 ID
• member_id：请求的 etcd 节点 ID
• revision：etcd 服务端当前全局数据版本号
  对任一 key 的 put 或 delete 操作都会使 revision 自增 1
  revision = 1 是 etcd 的保留版本号，因此用户的 key 版本号将从 2 开始
• raft_term：etcd 当前 raft 主节点任期号
• create_revision：当前 key 创建时全局数据版本号 revision 的值
• mod_revision：当前 key 最后一次修改时全局数据版本号 revision 的值
• version：当前 key 的数据版本号
  key 创建时 version = 1，对当前 key 进行 put 操作会使 version 自增 1，将 key 删除后，重新创建，version 又会从 1 开始计数