为什么是etcd
服务发现解决方案有很多,为什么不是zookeeper,consul等。马蜂窝技术做了个压测:
可以发现,etcd性能稳定,资源占用最少。此外,etcd相比其它还使用简单,部署方便。而且也是go开发的,同源。
服务发现
etcd不是一个高可用的分布式键值(key-value)数据库吗?它是怎么实现服务发现的?
实现机制是这样的:服务节点可以在etcd中注册服务名和节点地址,并且对注册的服务设置key TTL,定时保持服务的心跳以达到监控健康状态的效果。使用节点直接查询etcd数据库得到key-value。很简单,两句话就说明白了。
etcd很方便集群,Raft强一致性共识性算法保证每个etcd节点数据同步。
当然,这只是etcd的一个应用场景。
etcd安装
mac安装
brew install etcd
centos安装
yum install -y etcd
下载下来只有这么几个文件:
$ ls
Documentation etcd etcdctl README-etcdctl.md README.md READMEv2-etcdctl.md
etcd是server端,etcdctl是客户端。
运行:
$ ./etcd
etcd目前默认使用2379端口(客户端请求端口)和2380端口(其它节点连接端口)。etcd后面废了配置文件,推崇使用环境变量和命令行的配置。
查看配置:
$ etcd -h
docker安装
$docker run -p 2379:2379 -p 2380:2380 -v /etc/ssl/certs/:/etc/ssl/certs/ quay.io/coreos/etcd:v3.3.1
etcd使用
etcd有两种操作方式,一种是基于HTTP的REST API操作方式,另一种是通过etcdctl客户端。
而对etcd的操作命令又可分为两大类,一类是数据库操作,另一类是非数据库操作。
数据库操作
数据库操作围绕对键值和目录的CRUD完整生命周期的管理。
etcd在键的组织上采用了层次化的空间结构(类似于文件系统中目录的概念),用户指定的键可以为单独的名字,如:testkey,此时实际上放在根目录/下面,也可以为指定目录结构,如/cluster1/node2/testkey,则将创建相应的目录结构。
非数据库操作
非数据类操作不直接对数据本身进行管理 ,而是负责围绕集群自身的一些配置。主要是备份、监测、集群管理等。
这些不是本文重点,网上文章很多。
etcd概念词汇表
Raft:etcd所采用的保证分布式系统强一致性的算法。
Node:一个Raft状态机实例。
Member: 一个etcd实例。它管理着一个Node,并且可以为客户端请求提供服务。
Cluster:由多个Member构成可以协同工作的etcd集群。
Peer:对同一个etcd集群中另外一个Member的称呼。
Client: 向etcd集群发送HTTP请求的客户端。
WAL:预写式日志,etcd用于持久化存储的日志格式。
snapshot:etcd防止WAL文件过多而设置的快照,存储etcd数据状态。
Proxy:etcd的一种模式,为etcd集群提供反向代理服务。
Leader:Raft算法中通过竞选而产生的处理所有数据提交的节点。
Follower:竞选失败的节点作为Raft中的从属节点,为算法提供强一致性保证。
Candidate:当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。
Term:某个节点成为Leader到下一次竞选时间,称为一个Term。
Index:数据项编号。Raft中通过Term和Index来定位数据。
集群
因为共识性算法原因,要选出master。所以集群中节点个数最好为奇数个,最少为3个。
构建集群有三种方式:
- 静态配置集群信息
- 动态发现
- DNS域名服务发现
方式网上也很多,不作过多介绍
集群配置注意事项
- 时钟同步
集群各个节点时钟差异不超过1s,否则可能会导致raft协议异常。 - 节点操作
无论是添加、删除还是迁移节点,都要一个一个地进行,等集群中状态稳定后,再操作下一个节点。 - 故障处理
如果是某个节点出现故障了,可能本地数据已经过期甚至是格式破坏了。保险做法是先通过命令删除该节点,然后清空数据目录,再重新作为空节点加入。 - 重启集群
找到一个数据记录完整且比较新的节点,先以它为唯一节点创建新的集群,然后将其它节点一个一个地添加进来。