ETCD基本原理

2020年8月27日

在研究DCache过程中,发现其计划使用ETCD作为RouterServer的分布式协调组件,所以顺便研究了一下,帮助大家了解ETCD的功能、用途以及重要原理。

1 简介

1.1 功能特性

       ETCD是一种用于实现共享配置服务发现的分布式一致性系统,具备如下功能特性: 

  • GO语言实现的,K/V分布式一致性存储系统
  • 提供HTTP API, 支持POST/GET/DELETE操作
  • 支持SSL客户端安全认证
  • 支持KEY持有TTL属性
  • 支持目录(树形)操作
  • 支持多KEY的事务操作

1.2 架构说明

HTTP Server:用于处理客户端HTTP请求

Store:用于处理客户端大部分事务(读)

Raft:etcd的一致性协议,核心模块,数据新增或变更时调用Raft模块;

WAL:Write ahead Log,预写式日志,是etcd的持久化存储方式

Snapshot,是为了防止日志文件过多而进行的快照存储

Entry,是存储日志的具体内容。

1.3 用途

鉴于ETCD的上述特性,其可以应用于:配置中心、服务注册发现、选主、分布式锁、应用调度,分布式队列,等等场景中。

1.4 与zookeeper对比

与zookeeper对比,etcd在项目实现,一致性协议易理解性,运维,安全等多个维度上,都占据优势。

1、一致性协议

etcd使用raft协议,zk使用zab(类paxos协议),前者易于理解,方便工程实现。ZooKeeper的部署、维护、使用比较复杂,需要安装客户端。

2、多语言适配

etcd提供http+json,grpc接口,跨平台语言;zk则需要使用其专用客户端,且官方只提供了Java和C两种语言的接口。

3、访问安全方面

etcd支持https访问,zk在这方面缺失。

5、etcd读写性能

每个实例每秒支持一千次写操作。这个性能还是相当可观的。越多,由于数据同步涉及到网络延迟,会根据实际情况越来越慢,而读性能会随之变强,因为每个节点都能处理用户请求。

2 基本概念

2.1 超时时间

在Raft算法中有2种超时设置:

1、选举超时时间(electric timeout)

        当follower超过此时间未收到leader的心跳消息,会先发起投票,选举Leader。

2、心跳超时时间(heartbeat timeout)

  • Leader定时(heartbeat timeout)向follower发送心跳消息,日志复制是随着心跳消息发送的。

2.2 term

新的leader时代,每发生一次leader选举,都会刷新term值+1。

2.3 角色

ETCD中存在3种角色

  • leader
  • follower
  • candidate

3 一致性算法 --Raft

分布式协调系统的一致性算法,主要体现在选举和日志复制的过程中。

3.1 选举过程

1、所有节点初始状态为 follower

2、当 follower 没有收到 Leader的心跳时,角色就转变为 candidate,更新term值;投票给自己,然后给其他 follower发vote请求;

  • 如果此时集群里有其他 candidate,也发起了投票(vote)请求,则follwer的投票响应遵循“先到先得”原则,并且只能投票给一个candidate;也就是说谁的投票请求先到达 follower,谁就会获得该follower的投票;后到达的投票请求无法获得投票(即voteResponse中标识位为false) 。
  • 收到投票请求的节点会重置自己的选举超时时间,避免发起重复选举;

3、当candidate获得集群中半数以上的投票时,升级为Leader,开始日志复制。

4、当多个candidate收集到的票数相同,且commitIndex一致的情况下,会等待一个选举周期,进行下一次选举;

3.2 日志复制(Log replication)

3.2.1 二阶段提交

  1. leader接到客户端请求,会先写log;
  2. 将请求log发送给所有follower;follower跟leader一样写log,成功后给予响应;
  3. Leader 统计响应,如有超过半数响应成功,leader本地提交,响应客户端,然后发送commit消息给follower;
  4. follower接收到commit消息后提交本地变更
  5. 最终达到数据一致性

3.2.2 异常情况

某个follower出现异常,恢复后的数据同步:

  1. 如果在同步过程中有1个follower掉线,这个节点收不到后续的数据内容
  2. 在Leader节点上会维护每个follower当前的 commitIndex,并一直尝试发送 commitIndex 的提交请求;
  3. 当这个节点恢复后,状态仍为follower,等待leader消息;
  4. leader消息到来,follower提交本地 commitIndex 这条数据;
  5. 循环这个过程,直到 follower数据与其他节点一致;

3.4 重新选举

  1. 当leader宕机或网络异常时,follower在超过选举超时时间(electic timeout)后,变成cadidate,进入投票选举过程
  2. cadidate发起投票,重复“选举过程”

3.5 其他情况

当各follower数据不一致时,选举流程如下:

1、cadidate给 follower发送 vote请求,并附带以下信息

  • term,这个cadidate当前所处的选举周期
  • lastLogIndex,log中最新Index的位置
  • lastLogTerm,log中最新Index是在哪个选举周期产生的

2、follower在接收到vote请求时,会跟自身情况对比,每个follower保存的信息有:

  • currentTerm,follower所处的选举周期;
  • Log[],本节点上的数据;
  • commitIndex, log中最后一个提交的index;

3、比较规则:

  • 先看是否处于同一选举周期,若term < currentTerm,follower对此投票请求不予理睬(返回false);
  • 如果follower已经购票给了别人,则返回false;
  • 如果处于同一选举周期,再看数据的新旧程度;若 lastLogIndex
  • 以上都满足,则反馈投票,并等待选举结束;

3.6 参考资料

Raft动画演示:Raft

Raft一致性算法演示:Raft Consensus Algorithm

4 其他问题

4.1 日志压缩

  1. Log是以追加的方式写入的,会越来越大;
  2. 对log采用快照的方式进行备份;并清理log中已备份、提交的内容
  3. 快照的另一个作用是:当有新节点加入时,或者某一个follower落后较多时,可以通过快照加载数据
  4. Leader必须偶尔发送一次快照给follower

4.2 客户端访问流程

  1. 客户端随机挑选一台etcd通信
  2. 如果不是leader,请求会被拒绝;follower会在响应消息中携带接收到的 leader(地址)信息;
  3. 客户端再次发送请求到Leader,进行交互;
  4. 如果Leader这时候挂了,客户端访问会超时,等待一段时间重复这个过程。

5 总结

etcd工作流程总结:

  1. 所有节点在leader,cadidate,follower之间切换
  2. 在选举阶段,cadidate向其他节点发送vote请求;最终只有包含所有最新数据的节点才能升级为leader;
  3. 在数据同步阶段,采用二阶段提交:
  • Leader在收到客户端变更请求后,先将数据写入本地log,然后发送给所有follower;
  • follower接受数据后给予成功或失败响应;
  • Leader在收到超过半数的成功响应后,提交本地log,并广播提交给follower;
  • follower在收到提交确认后提交数据

你可能感兴趣的:(工具使用,etcd,java,服务器,raft,分布式一致性)