简介
etcd是CoreOS团队于2013年6月发起的开源项目，是一个分布式、可靠 key-value 存储的分布式系统。当然，它不仅仅用于存储，还提供共享配置及服务发现。
向etcd 注册 该服务（其实就是 存一个值）然后向etcd 发送心跳，当etcd 没有检测到心跳就会 把这个键值对 删了(这整个动作是etcd里的租约模式)，网关那边 就只需要 watch 这个 key ，就能够知道 所有服务的所有动态了
etcd现在用于制作服务发现是比较常见的。用一篇文章记录一下如何安装、配置、使用。以及介绍一些etcd的工作原理，术语。
etcd术语
| 术语 | 说明 |
|---|---|
| Term | 选举任期，每次选举之后递增 |
| Vote | 选举时一张投票 |
| Entry | Raft算法的日志的一个条目 |
| Candidate | 候选人，参与竞选的节点 |
| Leader | 领导，负责主动处理写入请求的节点 |
| Follower | 跟随着，不负责主动写入，仅仅从Leader同步数据 |
| Commit | 提交，序列化数据写入到日志中 |
| Propose | 提议，请求大部分节点同意数据写入 |
| Consensus | 一致性 |
安装
因为etcd是go语言编写的，安装只需要下载对应的二进制文件，并放到合适的路径就行。
解压后是一些文档和两个二进制文件etcd和etcdctl。etcd是server端，etcdctl是客户端。
配置
etcd的配置文件时使用的yaml文件格式。
name: 'single-etcd'
listen-peer-urls: http://0.0.0.0:2381 # 用于指定etcd和客户端的连接端口
listen-client-urls: http://0.0.0.0:2382 # 用于指定etcd服务器之间通讯的端口
auto-compaction-retention: '2' # 防止跑得太久了之后无法出现碎片太多的问题
启动命令行：
./etcd --config-file etcd-single.yml
@REM 设置连接地址直接查看当前的etcd的情况
etcdctl --endpoints=127.0.0.1:2381 endpoint status
127.0.0.1:2381, 8e9e05c52164694d, 3.5.0, 25 kB, true, false, 2, 4, 4,
我们可以通过使用指令来查询里面的信息。
PS C:\Users\abel> etcdctl --endpoints=127.0.0.1:2381 put /test/key "test kubernetes"
OK
PS C:\Users\abel> etcdctl --endpoints=127.0.0.1:2381 get /test/key
/test/key
test kubernetes
/all/server
基本用法
服务发现：服务器将会往etcd中的key里面写入自己的服务器连接信息，并且将
写入的时候，使用租赁的方式，意味着如果租赁结束了，这个数据将会
被删除掉。客户端将会在启动的时候获取一次etcd里面信息，并且使用
watch操作，监听这个etcd中的key里面的信息的变换。当某个服务器
挂掉了，或者开始工作了，就能读取到数据。
数据共享：类似于redis的用法，直接将数据写入到黑板上，连接上的服务器可以
在里面查询到存储从信息。
raft算法
一致性算法是在复制状态机的背景中被提出来的。指的是在一组服务器中产生同样状态的副本，因此即使一些机器发生故障之后仍然能正常工作。复制状态机被用于解决分布式系统中的容错处理。zookeeper 中就使用了复制状态机。在这之前还有一种叫做Paxos算法。复制状态机是通过复制日志来实现的。每一台服务器保存着一份日志，日志中包含一系列的命令，状态机会按顺序执行这些命令。因为每一台计算机的状态机都是确定的，所以每个状态机的状态都是相同的，执行的命令是相同的，最后的执行结果也就是一样的了。如何保证复制日志的一致就是一致性算法的工作内容。
一致性算法共性：
确保安全性（从来不会返回错误的结果）在所有的非拜占庭问题的条件下，包括网络延迟、分区、丢包、乱序等情况
可用性 只要集群中大多数节点能够彼此通信，也能和客户端保持通信、
不依赖定时去确保日志的一致性
通常情况下，只要集群中大多数节点对一轮 RPC 调用做出了相应，一条命令即可被视为已经完成。集群中少部分慢的节点不会影响整个系统的性能。
Raft和现有算法的特性：
Strong leader: raft 和其他一致性算法相比， 采用了一种更强力的领导策略。 比如， 日志条目只允许从领导到服务器。 这样简化了对于重复日志的管理，并让 raft 更加容易理解。
Leader election: raft 采用随机定时器来选举领导。 这样只需要在心跳中加入少量的随机策略，就能简单迅速的解决冲突问题
Membership changes:: raft 在调整聚群成员的时候采用了一种联合一致性（ joint consensus）的机制。这样当配置改变的时候，集群可以继续运行
工作原理，先看演示动画。有时间再看别人的笔记。最后看论文。
报错信息etcdserver: mvcc: database space exceeded
- 将启动语句增加auto-compaction-retention参数。
nohup etcd --auto-compaction-retention=1 --config-file etcd1.yml >> /root/lib/etcd-v3.5.0-linux-amd64/etcd1.log &
- 重新启动etcd之后，使用命令将etcd空间清理掉
#使用API3
export ETCDCTL_API=3
# 查看告警信息，告警信息一般 memberID:8630161756594109333 alarm:NOSPACE
etcdctl --endpoints=http://0.0.0.0:2382 alarm list
# 获取当前版本
rev=$(etcdctl --endpoints=http://0.0.0.0:2382 endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*')
# 压缩掉所有旧版本
etcdctl --endpoints=http://0.0.0.0:2382 compact $rev
# 整理多余的空间
etcdctl --endpoints=http://0.0.0.0:2382 defrag
# 取消告警信息
etcdctl --endpoints=http://0.0.0.0:2382 alarm disarm
➜ etcd-v3.5.0-linux-amd64 etcdctl --endpoints=http://0.0.0.0:2382 endpoint status
http://0.0.0.0:2382, 7d5020cb43815ca4, 3.5.0, 488 MB, false, false, 9, 23114017, 23114017,
➜ etcd-v3.5.0-linux-amd64 etcdctl --endpoints=http://0.0.0.0:2381 endpoint status
http://0.0.0.0:2381, b49ab97cd90e450b, 3.5.0, 704 MB, true, false, 9, 23116118, 23116118,
➜ etcd-v3.5.0-linux-amd64 etcdctl --endpoints=http://0.0.0.0:2379 endpoint status
http://0.0.0.0:2379, 3d9c87710817443b, 3.5.0, 2.1 GB, false, false, 9, 23116138, 23116138,
空间还是占了2.1GB
尝试使用etcd制作服务发现
服务器启动的时候开启一个租赁obj
将服务器的信息捆绑租赁写入到etcd
客户端watch服务器写入的数据key，当服务器关闭或者更新数据的时候将会有通知。
引用
- [1] etcd
- [2] Etcd 使用入门
- [3] 实战etcd的服务发现
- [4] etcd服务发现
- [5] raft算法
- [5] raft-algorithm-paper
- [6] raft-演示动画
- [7] 通过etcd制作服务发现
1844
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
