etcd-初识

北京时光

于 2021-04-08 17:45:06 发布

阅读量188

点赞数

分类专栏： etcd 文章标签： etcd

本文链接：https://blog.youkuaiyun.com/qq_30861013/article/details/115201959

版权

2 篇文章

订阅专栏

本文深入探讨了Etcd使用Raft算法进行数据一致性保障的原理，包括选举过程、数据提交、日志复制机制，以及如何处理不适合的leader和容量管理。重点介绍了灾备策略和高可用解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

采用 Raft算法

leader：对客户端通信的入口，对内数据同步的发起者，一个集群通常只有一个leader节点
follower:非leader的节点，被动的接受来自leader的数据请求
candidate: 一种临时的角色，只存在于leader的选举阶段，某个节点想要变成leader，那么就发起投票请求，同时自己变成candidate。如果选举成功，则变为candidate，否则退回为follower

注意：term作为逻辑时钟而存在。每个节点都保存一个单调递增的term编号，用于在RPC通信时进行鉴别。如果一个节点收到更高term的请求或心跳，则其更新自己的term为此更高的term

初始状态下，大家都是平等的follower，每个follower内部都维护了一个随机的timer。并且term=0 代表第一次选举
在timer时间到了的时候还没有人主动联系它的话，那它就要变成candidate，同时发出投票请求（RequestVote）给其他人。term=1
每个follower一轮只能投一次票给一个candidate
对于相同条件的candidate，follower们采取先来先投票的策略。如果超过半数的follower都认为他是合适做领导的，那么新的leader产生了
leader定期发心跳检测，如果在timer期间内没有收到大leader的联络，所有follower又开始新的一轮(term)选举开始了。
不适合的candidate
如果某节点S4成功当选的话，S4的log在index为4-7的数据，会覆盖掉S2和S3的8。如何解决这样的冲突的问题呢？有两种方法：
第一种是S4在变为大哥之前，先向所有的小弟拿数据来保证自己数据是最全的；
第二种方法是其他小弟遇到这样资历不足的大哥想上位的时候，完全不予以理睬。
Raft算法认为第一种策略过于复杂，所以选择了第二种

每次有数据更新的时候产生二阶段提交（two-phase commit）。
在leader收到数据操作的请求，先不着急更新本地数据（数据是持久化在磁盘上的），而是生成对应的log，然后把生成log的请求广播给所有的follower。
每个follower在收到请求之后有两种选择：一种是听从leader的命令，也写入log，然后返回success回去；另一种情况，在某些条件不满足的情况下，follower认为不应该听从leader的命令，返回false。
然后回到leader，此时如果超过半数的follower都成功写了log，那么leader开始第二阶段的提交：正式写入数据，然后同样广播给follower，follower也根据自身情况选择写入或者不写入并返回结果给leader。继续上面的例子，leader先写自己的数据，然后告诉follower也开始持久化数据
最终所有节点的数据达成一致，图中用实线表示已提交的数据。
这两阶段中如果任意一个都有超过半数的follower返回false或者根本没有返回，那么这个分布式事务是不成功的。此时虽然不会有回滚的过程，但是由于数据不会真正在多数节点上提交，所以会在之后的过程中被覆盖掉。