深刻浅出etcd系列Part 1 – etcd架构和代码框架

一、绪论

etcd做为华为云PaaS的核心部件，实现了PaaS大多数组件的数据持久化、集群选举、状态同步等功能。如此重要的一个部件，咱们只有深刻地理解其架构设计和内部工做机制，才能更好地学习华为云Kubernetes容器技术，笑傲云原生的“江湖”。本系列将从总体框架再细化到内部流程，对etcd的代码和设计进行全方位解读。本文是《深刻浅出etcd》系列的第一篇，重点解析etcd的架构和代码框架，下文所用到的代码均基于etcd v3.2.X版本。

另，由华为云容器服务团队倾情打造的《云原生分布式存储基石：etcd深刻解析》一书已正式出版，各大平台均有发售，购书可了解更多关于分布式key—value存储和etcd的相关内容！

二、etcd简介

etcd是一个分布式的key-value存储系统，底层经过Raft协议进行leader选举和数据备份，对外提供高可用的数据存储，能有效应对网络问题和机器故障带来的数据丢失问题。同时它还能够提供服务发现、分布式锁、分布式数据队列、分布式通知和协调、集群选举等功能。为何etcd如此重要？由于etcd是Kubernetes的后端惟一存储实现，绝不夸张地说，etcd就是Kubernetes的“心脏”。

2.1 Raft协议

要理解etcd分布式协同的工做原理，必须提到Raft算法。Raft算法是斯坦福的Diego Ongaro、John Ousterhout两人以易懂（Understandability）为目标设计的一致性共识算法。在此以前，提到共识算法(Consensus Algorithm)必然会提到Paxos，可是Paxos的实现和理解起来都很是复杂，以致于Raft算法提出者的博士论文中，做者提到，他们用了将近一年时间研究这个算法的各类解释，但仍是没有彻底理解这个算法。Paxos的算法原理和真正实现也有很大的距离，实现Paxos的系统，如Chubby，对Paxos进行了不少的改进有优化，可是细节倒是不为人所知的。 Raft协议采用分治的思想，把分布式协同的问题分为3个问题：

• 选举： 一个新的集群启动时，或者老的leader故障时，会选举出一个新的leader；

• 日志同步： leader必须接受客户端的日志条目而且将他们同步到集群的全部机器；

• 安全： 保证任何节点只要在它的状态机中生效了一条日志条目，就不会在相同的key上生效另外一条日志条目。

 

一个Raft集群通常包含数个节点，典型的是5个，这样能够承受其中2个节点故障。每一个节点实际上就是维护一个状态机，节点在任什么时候候都处于如下三种状态中的一个。

• leader：负责日志的同步管理，处理来自客户端的请求，与Follower保持这heartBeat的联系；

• follower：刚启动时全部节点为Follower状态，响应Leader的日志同步请求，响应Candidate的请求，把请求到Follower的事务转发给Leader；

• candidate：负责选举投票，Raft刚启动时由一个节点从Follower转为Candidate发起选举，选举出Leader后从Candidate转为Leader状态。

节点启动之后，首先都是follower状态，在follower状态下，会有一个选举超时时间的计时器(这个时间是在配置的超时时间基础上加一个随机的时间得来的)。若是在这个时间内没有收到leader发送的心跳包，则节点状态会变成candidate状态，也就是变成了候选人，候选人会循环广播选举请求，若是超过半数的节点赞成选举请求，则节点转化为leader状态。若是在选举过程当中，发现已经有了leader或者有更高的任期值的选举信息，则自动变成follower状态。处于leader状态的节点若是发现有更高任期值的leader存在，则也是自动变成follower状态。

Raft把时间划分为任期(Term)(以下图所示)，任期是一个递增的整数，一个任期是从开始选举leader到leader失效的这段时间。有点相似于一届总统任期，只是它的时间是不必定的，也就是说只要leader工做状态良好，它可能成为一个独裁者，一直不下台。

2.2 etcd的代码总体架构

etcd总体架构以下图所示： 

从大致上能够将其划分为如下4个模块：

- http：负责对外提供http访问接口和http client 

- raft 状态机：根据接受的raft消息进行状态转移，调用各状态下的动做。 

- wal 日志存储：持久化存储日志条目。 

- kv数据存储：kv数据的存储引擎，v3支持不一样的后端存储，当前采用boltdb。经过boltdb支持事务操做。 

相对于v2，v3的主要改动点为：

1. 使用grpc进行peer之间和与客户端之间通讯；

2. v2的store是在内存中的一棵树，v3采用抽象了一个kvstore，支持不一样的后端存储数据库。加强了事务能力。 

去除单元测试代码，etcd v2的代码行数约40k，v3的代码行数约70k。

2.3 典型内部处理流程

咱们将上面架构图的各个部分进行编号，以便下文的处理流程介绍中，对应找到每一个流程处理的组件位置。

2.3.1 消息入口

一个etcd节点运行之后，有3个通道接收外界消息，以kv数据的增删改查请求处理为例，介绍这3个通道的工做机制。 1. client的http调用：会经过注册到http模块的keysHandler的ServeHTTP方法处理。解析好的消息调用EtcdServer的Do()方法处理。(图中2) 2. client的grpc调用：启动时会向grpc server注册quotaKVServer对象，quotaKVServer是以组合的方式加强了kvServer这个数据结构。grpc消息解析完之后会调用kvServer的Range、Put、DeleteRange、Txn、Compact等方法。kvServer中包含有一个RaftKV的接口，由EtcdServer这个结构实现。因此最后就是调用到EtcdServer的Range、Put、DeleteRange、Txn、Compact等方法。(图中1) 3. 节点之间的grpc消息：每一个EtcdServer中包含有Transport结构，Transport中会有一个peers的map，每一个peer封装了节点到其余某个节点的通讯方式。包括streamReader、streamWriter等，用于消息的发送和接收。streamReader中有recvc和propc队列，streamReader处理完接收到的消息会将消息推到这连个队列中。由peer去处理，peer调用raftNode的Process方法处理消息。(图中三、4)

2.3.2 EtcdServer消息处理

对于客户端消息，调用到EtcdServer处理时，通常都是先注册一个等待队列，调用node的Propose方法，而后用等待队列阻塞等待消息处理完成。Propose方法会往propc队列中推送一条MsgProp消息。 对于节点间的消息，raftNode的Process是直接调用node的step方法，将消息推送到node的recvc或者propc队列中。 能够看到，外界全部消息这时候都到了node结构中的recvc队列或者propc队列中。(图中5)

2.3.3 node处理消息

node启动时会启动一个协程，处理node的各个队列中的消息，固然也包括recvc和propc队列。从propc和recvc队列中拿到消息，会调用raft对象的Step方法，raft对象封装了raft的协议数据和操做，其对外的Step方法是真正raft协议状态机的步进方法。当接收到消息之后，根据协议类型、Term字段作相应的状态改变处理，或者对选举请求作相应处理。对于通常的kv增删改查数据请求消息，会调用内部的step方法。内部的step方法是一个可动态改变的方法，将随状态机的状态变化而变化。当状态机处于leader状态时，该方法就是stepLeader；当状态机处于follower状态时，该方法就是stepFollower；当状态机处于Candidate状态时，该方法就是stepCandidate。leader状态会直接处理MsgProp消息。将消息中的日志条目存入本地缓存。follower则会直接将MsgProp消息转发给leader，转发的过程是将先将消息推送到raft的msgs数组中。 node处理完消息之后，要么生成了缓存中的日志条目，要么生成了将要发送出去的消息。缓存中的日志条目须要进一步处理(好比同步和持久化)，而消息须要进一步处理发送出去。处理过程仍是在node的这个协程中，在循环开始会调用newReady，将须要进一步处理的日志和须要发送出去的消息，以及状态改变信息，都封装在一个Ready消息中。Ready消息会推行到readyc队列中。(图中5)

2.3.4 raftNode的处理

raftNode的start()方法另外启动了一个协程，处理readyc队列(图中6)。取出须要发送的message，调用transport的Send方法并将其发送出去(图中4)。调用storage的Save方法持久化存储日志条目或者快照(图中九、10)，更新kv缓存。 另外须要将已经同步好的日志应用到状态机中，让状态机更新状态和kv存储，通知等待请求完成的客户端。所以须要将已经肯定同步好的日志、快照等信息封装在一个apply消息中推送到applyc队列。

2.3.5 EtcdServer的apply处理

EtcdServer会处理这个applyc队列，会将snapshot和entries都apply到kv存储中去(图中8)。最后调用applyWait的Trigger，唤醒客户端请求的等待线程，返回客户端的请求。

三、重要的数据结构

3.1 EtcdServer

type EtcdServer struct {

    // 当前正在发送的snapshot数量

    inflightSnapshots int64 

    //已经apply的日志index

    appliedIndex      uint64 

    //已经提交的日志index，也就是leader确认多数成员已经同步了的日志index

    committedIndex    uint64 

    //已经持久化到kvstore的index

    consistIndex consistentIndex 

    //配置项

    Cfg          *ServerConfig

    //启动成功并注册了本身到cluster，关闭这个通道。

    readych chan struct{}

    //重要的数据结果，存储了raft的状态机信息。

    r       raftNode

    //满多少条日志须要进行snapshot

    snapCount uint64

    //为了同步调用状况下让调用者阻塞等待调用结果的。

    w wait.Wait

    //下面3个结果都是为了实现linearizable 读使用的

    readMu sync.RWMutex

    readwaitc chan struct{}

    readNotifier *notifier

    //中止通道

    stop chan struct{}

    //中止时关闭这个通道

    stopping chan struct{}

    //etcd的start函数中的循环退出，会关闭这个通道

    done chan struct{}

    //错误通道，用以传入不可恢复的错误，关闭raft状态机。

    errorc     chan error

    //etcd实例id

    id         types.ID

    //etcd实例属性

    attributes membership.Attributes

    //集群信息

    cluster *membership.RaftCluster

    //v2的kv存储

    store       store.Store

    //用以snapshot

    snapshotter *snap.Snapshotter

    //v2的applier，用于将commited index apply到raft状态机

    applyV2 ApplierV2

    //v3的applier，用于将commited index apply到raft状态机

    applyV3 applierV3

    //剥去了鉴权和配额功能的applyV3

    applyV3Base applierV3

    //apply的等待队列，等待某个index的日志apply完成

    applyWait   wait.WaitTime

    //v3用的kv存储

    kv         mvcc.ConsistentWatchableKV

    //v3用，做用是实现过时时间

    lessor     lease.Lessor

    //守护后端存储的锁，改变后端存储和获取后端存储是使用

    bemu       sync.Mutex

    //后端存储

    be         backend.Backend

    //存储鉴权数据

    authStore  auth.AuthStore

    //存储告警数据

    alarmStore *alarm.AlarmStore

    //当前节点状态

    stats  *stats.ServerStats

    //leader状态

    lstats *stats.LeaderStats

    //v2用，实现ttl数据过时的

    SyncTicker *time.Ticker

    //压缩数据的周期任务

    compactor *compactor.Periodic

    //用于发送远程请求

    peerRt   http.RoundTripper

    //用于生成请求id

    reqIDGen *idutil.Generator

    // forceVersionC is used to force the version monitor loop

    // to detect the cluster version immediately.

    forceVersionC chan struct{}

    // wgMu blocks concurrent waitgroup mutation while server stopping

    wgMu sync.RWMutex

    // wg is used to wait for the go routines that depends on the server state

    // to exit when stopping the server.

    wg sync.WaitGroup

    // ctx is used for etcd-initiated requests that may need to be canceled

    // on etcd server shutdown.

    ctx    context.Context

    cancel context.CancelFunc

    leadTimeMu      sync.RWMutex

    leadElectedTime time.Time

}

3.2 raftNode

raftNode是Raft节点，维护Raft状态机的步进和状态迁移。

type raftNode struct {

    // Cache of the latest raft index and raft term the server has seen.

    // These three unit64 fields must be the first elements to keep 64-bit

    // alignment for atomic access to the fields.

    //状态机当前状态，index表明当前已经apply到状态机的日志index，term是最新日志条目的term，lead是当前的leader id

    index uint64

    term  uint64

    lead  uint64

    //包含了node、storage等重要数据结构

    raftNodeConfig

    // a chan to send/receive snapshot

    msgSnapC chan raftpb.Message

    // a chan to send out apply

    applyc chan apply

    // a chan to send out readState

    readStateC chan raft.ReadState

    // utility

    ticker *time.Ticker

    // contention detectors for raft heartbeat message

    td *contention.TimeoutDetector

    stopped chan struct{}

    done    chan struct{}

}

3.3 node

type node struct {

    //Propose队列，调用raftNode的Propose即把Propose消息塞到这个队列里

    propc      chan pb.Message

    //Message队列，除Propose消息之外其余消息塞到这个队列里

    recvc      chan pb.Message

    //集群配置信息队列，当集群节点改变时，须要将修改信息塞到这个队列里

    confc      chan pb.ConfChange

    //外部经过这个队列获取修改后集群配置信息

    confstatec chan pb.ConfState

    //已经准备好apply的信息队列

    readyc     chan Ready

    //每次apply好了之后往这个队列里塞个空对象。通知能够继续准备Ready消息。

    advancec   chan struct{}

    //tick信息队列，用于调用心跳

    tickc      chan struct{}

    done       chan struct{}

    stop       chan struct{}

    status     chan chan Status

    logger Logger

}

 

四、小结

本文简要介绍了raft协议和etcd的框架,介绍了etcd内部的和消息流的处理。后续将分心跳和选举、数据同步、数据持久化等不一样专题详细讲述etcd的内部机制。