云原生 Etcd 系列之Quorum 和唱票那回事

云计算 云原生
唱票是在选举流程中的一个步骤。还记得以前选班干部的时候,在黑板上写“正”字,谁得票多谁就获胜当选。

[[438630]]

本文转载自微信公众号「奇伢云存储」,作者奇伢。转载本文请联系奇伢云存储公众号。

关于 Quorum 的两个维度

前几回说了那么多框架,设计思想的文章。今天分享一个很小的点,etcd 的 quorum 是怎么实现的?

Quorum 机制本质就是一个关于多数派的事情,这个多数派应用的有两个方面:

  • 选举过程:获得多数节点投票的节点才能获胜,成为 Leader ;
  • 运行过程:被多数节点 commit 的日志位置,这个才是被集群可靠记录的位置。被集群 commit 的日志才能被应用 apply ;

那么这里有两个小思考问题:

既然是选举过程,那怎么选举结果唱票的?

既然是运行过程,那集群的这些节点怎么确认集群的 commit 位置?

有选举自然有唱票

唱票是在选举流程中的一个步骤。还记得以前选班干部的时候,在黑板上写“正”字,谁得票多谁就获胜当选。

etcd 里面也有选举,也就是 Leader 的选举。Leader 获胜的依据是的票满足大多数,也就是满足 quorum 机制。

今天我们就来看看 etcd 的唱票是怎么做的?

很简单的思路,我们给每个参与选举的朋友计数,得票超过半数的,那么就胜出。

比如说 A,B,C,D,E 五个人竞选,那么得到 3 票的就可以胜出。

来看看 etcd 的唱票

选举属于 quorum 机制,代码位于 etcd/raft/quorum/ 下。quorum 的核心实现在 MajorityConfig 的结构体,其实就是个 map 的封装:

  1. type MajorityConfig map[uint64]struct{} 

这个 map 的 key 是节点的 id,这里面包含了集群的节点,map 的 value 不重要,所用用的是 struct{} 类型。

思考个小问题:那既然 value 不 care ,那为什么不用 slice 结构?

其实就是为了查找的需求,map 的查找是常数级别,value 又用的 struct{} ,不占空间,一举两得。

  1. // etcd/raft/quorum/majority.go 
  2. func (c MajorityConfig) VoteResult(votes map[uint64]bool) VoteResult { 
  3.     // 搞个长度为 2 的数组 
  4.     ny := [2]int{} 
  5.     // 遍历集群节点 
  6.     for id := range c { 
  7.         v, ok := votes[id] 
  8.         if !ok { 
  9.             // 暂时没投票的 
  10.             missing++ 
  11.             continue 
  12.         } 
  13.         if v { 
  14.             // 投票赞同的 
  15.             ny[1]++ 
  16.         } else { 
  17.             // 投票拒绝的 
  18.             ny[0]++ 
  19.         } 
  20.     } 
  21.     q := len(c)/2 + 1 
  22.     if ny[1] >= q { 
  23.         // 选举成功:得票数超过半数,,比如 votes => [yes, yes, yes] 
  24.         return VoteWon 
  25.     } 
  26.     if ny[1]+missing >= q { 
  27.         // 未知情况:不确定成功,也不确定失败 
  28.         return VotePending 
  29.     } 
  30.     // 选举失败 
  31.     return VoteLost 

唱票的实现很简单,就如下几个步骤:

  • 遍历集群节点;
  • 统计谁赞同了、谁拒绝了、谁还没投票;
  • 唱票的结果有三种:成功,失败,待定;
  • 赞同投票的超过半数( len(c)/2+1 ),则胜利;

这实现可太简单了,就是一个遍历投票结果,写“正”字,“正”字超过半数则胜出。

集群的节点怎么确认集群的 commit 位置?

集群内被多数节点 commit 的位置才是集群的 commit 点。也就是说这个也需要满足 quorum 。这个就有意思了。

关键步骤:排序,然后取中间的位置。

取的这个中间的位置就是满足 quorum 的 commit 。

  1. // etcd/raft/quorum/majority.go 
  2. func (c MajorityConfig) CommittedIndex(l AckedIndexer) Index { 
  3.     // 遍历集群节点:取出每个节点的 commit 
  4.     for id := range c { 
  5.         if idx, ok := l.AckedIndex(id); ok { 
  6.             srt[i] = uint64(idx) 
  7.             i-- 
  8.         } 
  9.     } 
  10.     // 排个序 
  11.     insertionSort(srt) 
  12.  
  13.     // 取中间,这个位置就是大多数 commit 的位置,属集群共识 
  14.     pos := n - (n/2 + 1) 
  15.     return Index(srt[pos]) 

这个实现就很有意思了,捞出每个节点当前的 commit 位置,组成一个数组,然后给这个数组排个序,取中间的位置。这个位置就是集群的 commit 位置,也就是 apply 的位置。

先把集群每个节点的 commit 位置取出来,是这样的:

后来排个序是这样的,黑色的节点 commit 位置则是集群的 commit 位置:

总结

Quorum 机制是分布式系统中很重要的理论部分,这是一个关于多数派的机制。etcd 关于多数派有两个方面:Leader 选举和 raft 日志运行;

etcd 的唱票实现非常简单,就是一个计数“正”字的实现,用一个 map 记录集群的节点,投票计数超过多数则胜出;

etcd 确认集群 commit 位置则是先把每个节点的 commit 位置放在数组,然后排个序,然后取中间位置,这个位置就是集群的 commit 位置;

多数节点 commit 过的日志才是集群 commit 的位置,集群 commit 的日志才能 apply ,这个要记住喽;

 

集群 commit 位置将由 Leader 通过心跳或者日志复制的消息告诉其他节点;

 

责任编辑:武晓燕 来源: 奇伢云存储
相关推荐

2018-03-12 10:49:46

热管散热误区

2020-03-04 09:56:56

网络安全云原生容器

2021-07-13 07:52:03

云原生弹性模式

2013-05-27 09:32:07

构建私有云OpenStack开源云计算

2023-05-15 07:33:06

云原生自身业务云厂商

2021-11-15 08:00:00

云原生端点漏洞

2022-05-26 15:02:35

Docker容器云原生

2021-04-13 05:38:35

Kubernetes存储数据库

2017-03-24 17:55:47

互联网

2022-12-15 11:26:44

云原生

2022-10-27 18:03:04

GogRPC云原生

2022-04-25 12:39:57

云原生云计算

2022-07-20 15:19:17

容器Docker

2017-03-24 18:38:40

互联网

2021-10-29 10:12:34

云原生勒索软件网络攻击

2021-10-19 13:46:41

云原生 阿里云”服务器

2022-02-08 07:56:38

云厂商云计算云服务

2020-12-19 21:07:42

腾讯云云原生容器

2022-02-02 21:37:57

云计算全栈云运营

2018-09-20 20:46:51

云原生CNBPS灵雀云
点赞
收藏

51CTO技术栈公众号