peer-cert-allowed-cn    允许的客户端证书CommonName    your name or your server's hostname

设置etcd存储大小
etcd --quota-backend-bytes=$((16*1024*1024))

写爆磁盘
while [ 1 ]; do dd if=/dev/urandom bs=1024 count=1024 | etcdctl put key || break;done

查看endpoint状态
etcdctl --write-out=table endpoint status

查看alarm
etcdctl alarm list

清理碎片
etcdctl defrag

清理alarm
etcdctl alarm disarm

获取当前etcd数据的修订版本(revision)
rev=$(etcdctl -w json endpoint status | egrep -o -i '"revision":[0-9]*' | egrep -o '[0-9]*')

# 获取etcd当前版本号
$ rev=$(etcdctl endpoint status --write-out="json" | egrep -o -i '"revision":[0-9]*' | egrep -o '[0-9].*')
整合压缩旧版本数据 执行压缩操作,指定压缩的版本号为当前版本号
etcdctl compact $rev
执行碎片整理
etcdctl defrag
解除告警
etcdctl alarm disarm
备份以及查看备份数据信息
etcdctl snapshot save backup.db
etcdctl snapshot status backup.db

//--auto-compaction-mode=revision --auto-compaction-retention=1000 每5分钟自动压缩"latest revision" - 1000；
//--auto-compaction-mode=periodic --auto-compaction-retention=12h 每1小时自动压缩并保留12小时窗口.
👁etcd_backend/embed/config_test.go:TestAutoCompactionModeParse

- 只保存一个小时的历史版本`etcd --auto-compaction-retention=1`
- 只保留最近的3个版本`etcdctl compact 3`
- 碎片整理`etcdctl defrag`

http:https://127.0.0.1:2379/members

curl    --------http--------->    gateway ------------> etcd grpc server 2379
                            将http转换成了grpc



127.0.0.1:2379
1、HTTP2
2、HTTP1     

etcdServer 会单独处理 Propose消息, 其余消息交给raft.step 来处理 [该函数,会随着节点角色的改变而发生改变] [会首先判断任期、索引,在判断消息类型]

StartEtcd
  1、etcdserver.NewServer -> 
      heartbeat := time.Duration(cfg.TickMs) * time.Millisecond
      MySelfStartRaft
        newRaftNode
          r.ticker = time.NewTicker(r.heartbeat)                创建定时器、心跳
        startNode -> 
          raft.StartNode -> 
            go n.run()
              rd = n.rn.readyWithoutAccept()                      获取待发送消息,会获取到r.msgs
              readyc = n.readyc                                   待发送消息channel 
              - case pm := <-propc                                网络发来的消息、除Propose消息
              - case m := <-n.recvc                               G 处理来自peer的消息 
              - case cc := <-n.confc
              - case <-n.tickc                                    F取出数据
                  n.rn.Tick()
                    rn.raft.tick()                                根据角色调用自己的函数
                      - r.tickElection 
                          r.Step(pb.Message{From: r.id, Type: pb.MsgHup}) 该函数是处理所有到来消息的入口
                            r.send(pb.Message
                              r.msgs = append(r.msgs, m)          放入要发送的消息
                      - r.tickHeartbeat
                          r.Step(pb.Message{From: r.id, Type: pb.MsgCheckQuorum})
              - case readyc <- rd                                                   A放入数据
              - case <-advancec: 
              - case c := <-n.status:
              - case <-n.stop: 
      tr.AddPeer  
        startPeer                                                 与每个peer都建立一个链接
          r.Process
            s.Process
              s.r.Step(ctx, m)
                n.step
                  stepWithWaitOption
                    case n.recvc <- m                             G 接收来自peer的消息 
        
  2、e.Server.Start ->
    EtcdServer.strat ->
      s.start()
        go s.run() 
            --> | # s.r=raftNode
            --> | s.r.start(rh)
            --> |   go func()
            --> |     - case <-r.ticker.C:                          接收定时器信号
            --> |       r.tick() 
            --> |         r.Tick()
            --> |           case n.tickc <- struct{}{}              F放入数据、不会阻塞,有size
            --> |     - case rd := <-r.Ready()                      获取可以发送的数据     A取出数据  
                          case r.applyc <- ap                                           B放入数据
                          r.transport.Send(msgs)                        发出响应数据
            --> |     - case <-r.stopped:
            
          - case ap := <-s.r.apply()                                                   B取出数据
              读取applyc的数据,封装为JOB,放入调度器
          - case leases := <-expiredLeaseC
              处理过期租约
          - case err := <-s.errorc
              处理运行过程中出现的err,直接退出
          - getSyncC
          - case <-s.stop:
              启动过程中失败
    
  3、e.servePeers
  4、e.serveClients
  5、e.serveMetrics
    

快照 + storage + unstable 的区别
compacted <--- compacted <--- applied <--- committed <--- stable <--- unstable
WAL 日志 
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
-------------------------------------------------------------------|--MemoryStorage|file--|-----------------
-----压缩---------|---------------压缩---------------------|-------------------------------------------------
----快照----------------- |----------------快照--------------------- | storage: 落盘的       | unstable 内存中的  
----快照----------------- |----------------快照--------------------- |         | 在没有被持久化之前如果遇到了换届选举,这个日志可能会被相同索引值的新日志覆盖


每一条日志Entry需要经过unstable、stable、committed、applied、compacted五个阶段,接下来总结一下日志的状态转换过程:

刚刚收到一条日志会被存储在unstable中,日志在没有被持久化之前如果遇到了换届选举,这个日志可能会被相同索引值的新日志覆盖,这个一点可以在raftLog.maybeAppend()和unstable.truncateAndAppend()找到相关的处理逻辑.
unstable中存储的日志会被使用者写入持久存储（文件）中,这些持久化的日志就会从unstable转移到MemoryStorage中.
读者可能会问MemoryStorage并不是持久存储啊,其实日志是被双写了,文件和MemoryStorage各存储了一份,而raft包只能访问MemoryStorage中的内容.这样设计的目的是用内存缓冲文件中的日志,在频繁操作日志的时候性能会更高.
此处需要注意的是,MemoryStorage中的日志仅仅代表日志是可靠的,与提交和应用没有任何关系.
leader会搜集所有peer的接收日志状态,只要日志被超过半数以上的peer接收,那么就会提交该日志,peer接收到leader的数据包更新自己的已提交的最大索引值,这样小于等于该索引值的日志就是可以被提交的日志.
已经被提交的日志会被使用者获得,并逐条应用,进而影响使用者的数据状态.
已经被应用的日志意味着使用者已经把状态持久化在自己的存储中了,这条日志就可以删除了,避免日志一直追加造成存储无限增大的问题.不要忘了所有的日志都存储在MemoryStorage中,不删除已应用的日志对于内存是一种浪费,这也就是日志的compacted.

每次用户提交日志,该日志会保存到 MemoryStorage 以及wal里,每当raft发送给上层程序一批已经commited日志,就会触发maybeTriggerSnapshot,当用户apply以后
判断是否进行触发 MemoryStorage 打快照,当打了快照以后,会把当前快照点10000条以前的记录从 MemoryStorage.ents去除掉 【俗称压缩】



MemoryStorage并不是持久存储啊,其实日志是被双写了,文件和MemoryStorage各存储了一份,
而raft包只能访问MemoryStorage中的内容.这样设计的目的是用内存缓冲文件中的日志,在频繁操作日志的时候性能会更高.
此处需要注意的是,MemoryStorage中的日志仅仅代表日志是可靠的,与提交和应用没有任何关系.

1、新建Snapshot之后,一般会调用MemoryStorage.Compact()方法将MemoryStorage.ents中指定索引之前的Entry记录全部抛弃,
从而实现压缩MemoryStorage.ents 的目的,具体实现如下:    [GC]
func (ms *MemoryStorage) Compact(compactIndex uint64) 

2、清除kvindex的修订版本,以及bolt.db里的历史数据

type Record struct {
    Type                 int64   
    Crc                  uint32  
    Data                 []byte   
}
- metadataType  :1  元数据类型,元数据会保存当前的node id和cluster id.
    type Metadata struct {
        NodeID    uint64
        ClusterID uint64
    }
- entryType     :2  日志条目
    type Entry struct {
        Term  uint64
        Index uint64
        Type  EntryType  
                EntryNormal
                  # msgType
                EntryConfChange   
                EntryConfChangeV2 
        Data  []byte 
              msg 👆🏻
    }
- stateType     :3  当前Term,当前竞选者、当前已经commit的日志.
- crcType       :4  存放crc校验字段 Data为nil
- snapshotType  :5  快照的、日志的Index和Term
    type Snapshot struct {
        Index     uint64
        Term      uint64
        ConfState *raftpb.ConfState
    }

raft commit->apply  的数据 封装在ready结构体里   <-r.Ready()
    raftNode拿到该ready做一些处理,过滤出操作日志   publishEntries
        上层应用拿到过滤后的,将其应用到kvstore【【

1、先检查是否有待应用的变更
2、将变更信息放入raft unstable 等待发送----->发送,等到apply
3、apply 该变更
case rd := <-r.Ready(): 从raft拿到要apply的消息
  case r.applyc <- ap:
       go:
       - ap := <-s.r.apply()
        - s.applyAll(&ep, &ap)
         - s.applyEntries(ep, apply)
          - s.apply(ents, &ep.confState)
           - case raftpb.EntryConfChange:
            - s.applyConfChange(cc, confState, shouldApplyV3)
             - *s.r.ApplyConfChange(cc)     获取应用配置变更之后的集群状态      
              - cs := r.applyConfChange(cc) 返回应用配置变更之后的集群状态,已生效,只更新了quorum.JointConfig与peer信息
               - r.switchToConfig(cfg, prs) 
             -
               | s.cluster.PromoteMember 
               | s.cluster.AddMember                    -----> 更新v2store[memory node tree]、backend[bolt.db] 
               | s.cluster.RemoveMember                                     |---> 触发watcher
               | s.cluster.UpdateRaftAttributes 


r.Advance()

localNode.run() 一直死循环
  判断是否有ready的数据,其中 r.readStates就是一项指标
  n.readyc <- ready 
  
---------------------------------
raftNode.start
  case rd := <-r.Ready():           消费端:  获取ready数据,包含r.ReadStates = r.readStates
    select {
    case r.readStateC <- rd.ReadStates[len(rd.ReadStates)-1]:  // 发送响应数据
    case <-time.After(internalTimeout):
        r.lg.Warn("发送读状态超时", zap.Duration("timeout", internalTimeout))
    case <-r.stopped:
        return
    }
---------------------------------
leader:
    stepLeader;
    case pb.MsgReadIndex:
      1、集群只有一个节点  
        r.readStates = append(r.readStates, ReadState{Index:r.raftLog.committed, RequestCtx: 自增ID})
      2、
        引入pendingReadIndex、readIndexQueue 心跳广播 自增ID 等待大多数据集群节点回应 自增ID
    case pb.MsgHeartbeatResp:    
      rss := r.readOnly.advance(m)       

rd.ReadStates
----------------------------------
linearizableReadLoop                      发送MsgReadIndex消息,
    s.requestCurrentIndex
        1、s.sendReadIndex(自增ID)
            s.r.ReadIndex                 发送pb.MsgReadIndex消息,数据是自增ID
        2、case rs := <-s.r.readStateC:   等待响应   得到ReadState{Index:r.raftLog.committed, RequestCtx: 自增ID}
        return r.raftLog.committed
    r.raftLog.committed >= s.getAppliedIndex()     如果满足这个条件  
    nr.notify(nil)                        相当于往nc.c发消息       
--------------
get
linearizeReadNotify                    线性读,触发linearizableReadLoop,并等待结果
  1、case s.readwaitc <- struct{}{}:      触发线性读 
  2、case <-nc.c:                         等待结果
     return nc.err  
继续在本节点读取数据 
          

bug: 
  如果租约在到期前,Leader切换, 那么它的租约会重置
如何解决这个问题
  每过一段时间,将每个key剩余多长时间同步到其他节点的db中,这样如果发生leader切换,租约的误差也只是 这个间隔
  - 定期同步租约剩余时间至其他节点的db
issue:
  第一发送  ttl  10s  remainingTtl  5s
  假设将该消息发送到对端,因为网络问题花了3秒, 那么当对端收到时,实际remainingTtl应该是2s,但还是变成了5s  
- 如果时间这么长,那这个节点肯定出问题了,那么也不会成为leader


作者回复: 
从原理上我们知道lease是leader在内存中维护过期最小堆的,因此续期操作client是必须要直接发送给leader的,
如果follower节点收到了keepalive请求,会转发给leader节点.续期操作不经过raft协议处理同步,
而leaseGrant/Revoke请求会经过raft协议同步给各个节点,因此任意节点都可以处理它.

curl -L http:https://127.0.0.1:2379/version
curl -L http:https://192.168.59.156:2379/metrics
etcdctl cluster-health
etcdutl backup --data-dir /var/lib/etcd --backup-dir /tmp/etcd

# no crt 
etcdctl snap save a.db 
etcdctl snapshot restore a.db
# crt
etcdctl snap save --cert=./cert/server.crt --cacert=./cert/ca.crt --key=./cert/server.key a.db 

Step()
  case pb.MsgVote, pb.MsgPreVote:
    变更leader,....等操作
  
  stepLeader()
    case pb.MsgTransferLeader:
      r.send(pb.Message{To: to, Type: pb.MsgTimeoutNow})  // 给指定的节点发消息
  stepFollower()
    case pb.MsgTimeoutNow:
      r.hup(campaignTransfer)
      # 给每一个节点发送
      r.send(pb.Message{Term: term, To: id, Type: voteMsg, Index: r.raftLog.lastIndex(), LogTerm: r.raftLog.lastTerm(), Context: ctx})

#创建一个admin role 
etcdctl role add admin  --user root:root
#分配一个可读写[hello,helly)范围数据的权限给admin role
etcdctl role grant-permission admin readwrite hello helly --user root:root
# 将用户alice和admin role关联起来,赋予admin权限给user
etcdctl user grant-role alice admin --user root:root

从 etcd 的功能特性上分析, 因 etcd 支持范围查询,因此保存索引的数据结构也必须支持范围查询才行.所以哈希表不适合,而 B-tree 支持范围查询.
从性能上分析,平横二叉树每个节点只能容纳一个数据、导致树的高度较高,而 B-tree 每个节点可以容纳多个数据,
树的高度更低,更扁平,涉及的查找次数更少,具有优越的增、删、改、查性能.

采用延迟删除
1、为了保证key对应的watcher能够获取到key的所有状态信息,留给watcher时间做相应的处理.
2、实时从boltdb删除key,会可能触发树的不平衡,影响其他读写请求的性能.

etcd要保存key的历史版本,直接删除就不能支持revision查询了；
lazy方式性能更高,空闲空间可以再利用；

应该会增大,etcd不会立即把空间返回系统而是维护起来后续使用,维护空闲页面应该需要一些内存；

$ etcdctl txn -i
compares:
mod("Alice") = "2"
mod("Bob") = "3"

success requests (get, put, del):
put Alice 100
put Bob 300
 
success requests (get, put, del): //对应Then语句
put Alice 100 //Alice账号初始资金200减100
put Bob 300 //Bob账号初始资金200加100

failure requests (get, put, del): //对应Else语句
get Alice  
get Bob

若 etcd 节点内存不足,可能会导致 db 文件对应的内存页被换出.
当读请求命中的页未在内存中时,就会产生缺页异常,导致读过程中产生磁盘 IO.
这样虽然避免了 etcd 进程 OOM,但是此过程会产生较大的延时.

{
    "Key":"a",
    "Modified":{
        "Main":8,
        "Sub":0
    },
    "Generations":[
        {
            "VersionCount":4,
            "Created":{
                "Main":2,
                "Sub":0
            },
            "Revs":[
                {
                    "Main":2,
                    "Sub":0
                },
                {
                    "Main":3,
                    "Sub":0
                },
                {
                    "Main":4,
                    "Sub":0
                },
                {
                    "Main":5,
                    "Sub":0
                }
            ]
        },
        {
            "VersionCount":3,
            "Created":{
                "Main":6,
                "Sub":0
            },
            "Revs":[
                {
                    "Main":6,
                    "Sub":0
                },
                {
                    "Main":7,
                    "Sub":0
                },
                {
                    "Main":8,
                    "Sub":0
                }
            ]
        }
    ]
}