etcd选举机制

etcd是一种先进的key-value的存储系统，本文主要是学习etcd的心得，如有误解，敬请拍砖

主要分成三种形式的选举，先说一下etcd节点的三种状态，分别为leader,candidate和follower

第一种：初始选举

A、B、C、D现在进场，那么谁当领导呢？A(变身candidatae)就分别找BCD谈话，“我来当，你没意见吧”。B\C都没什么主见，就同意了，D虽然不同意，但是大家都这么说，只好也同意了。A就开始行使权利，定时从BCD同步日志，并发送心跳（heartbeat）

第二种，leader异常

A是领导，BCD是follower,大家正在工作。此时突然A肚子痛了上厕所（故障）,BCD都有事，但是没办法汇报。BCD就商量了，咱们重新选个领导吧！于是B（变身candidate）主动单独跟C、D询问，"我来当领导，你们有意见没有？"。CD都没有意见，于是B就当了领导，那么此时A刚好回来啦，就发现这一幕，怎么办？他们就一较高下，根据日志的步进数来决定谁当领导，因为A缺席了那么久，很多消息都没有，所以就失败了。于是A清理自己的消息，变成了follower。

第三种，follower异常

同上，但是肚子痛的是C，不是A。ABD正常工作，当C回来了,就直接成为follower。

第四种，初始的follower中在同一个时间同时变身（成为candidate）,

A去找C谈话了，B去跟D谈话了。C答应跟A，D答应跟B，此时A去问D就被直接拒绝了，B问C也同样被拒绝。A问B两人都是candidate，谁怕谁啊！你也拒绝我，我也拒绝你。那么四个人怎么办呢？A经过一个时间差（150ms~300ms）再次向C,D发起谈话，此时，C,D都同意了A（B还没有反应过来），此时A已经成为了leader，B发现已经有了leader了，重新成为了follower.

时间： 2024-10-12 14:45:42

etcd选举机制的相关文章

理解zookeeper选举机制

*:first-child { margin-top: 0 !important; } body>*:last-child { margin-bottom: 0 !important; } /* BLOCKS =============================================================================*/ p, blockquote, ul, ol, dl, table, pre { margin: 15px 0; } /* HEAD

Zookeeper中的选举机制

Zookeeper虽然在配置文件中并没有指定master和slave,但是,zookeeper工作时,是有一个节点为leader,其他则为follower.leader是通过内部的选举机制临时产生的. 选举机制大致可以分为以下两种: 1. 全新集群的选举机制 以一个简单的例子来说明整个选举的过程. 假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么. 1) 服务器

zookeeper leader选举机制

最近看了下zookeeper的源码,先整理下leader选举机制 先看几个关键数据结构和函数 服务可能处于的状态,从名字应该很好理解 public enum ServerState { LOOKING, FOLLOWING, LEADING, OBSERVING; } 选票参数,还有Notification,参数也都差不多 static public class ToSend { long leader; //leader id long zxid; //选票的zxid long electio

8.8.ZooKeeper 原理和选举机制

1.ZooKeeper原理 Zookeeper虽然在配置文件中并没有指定master和slave但是,zookeeper工作时,是有一个节点为leader,其他则为follower,Leader是通 过内部的选举机制临时产生的 2.ZooKeeper选举机制 2.1.概念 2.2. zk的选举机制(全新集群paxos):新搭建,无任何数据(通过myid) 2.3. 非全新集群的选举机制(数据恢复) 原文地址:https://www.cnblogs.com/yaboya/p/9149077.htm

zookeeper的选举机制

1)半数机制:集群中半数以上机器存活,集群可用.所以zookeeper适合装在奇数台机器上. 2)Zookeeper虽然在配置文件中并没有指定master和slave.但是,zookeeper工作时,是有一个节点为leader,其他则为follower,Leader是通过内部的选举机制临时产生的 3)以一个简单的例子来说明整个选举的过程. 假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器

zookeeper选举机制

在上一篇文章中我们大致浏览了zookeeper的启动过程,并且提到在Zookeeper的启动过程中leader选举是非常重要而且最复杂的一个环节.那么什么是leader选举呢?zookeeper为什么需要leader选举呢?zookeeper的leader选举的过程又是什么样子的?本文的目的就是解决这三个问题. 首先我们来看看什么是leader选举.其实这个很好理解,leader选举就像总统选举一样,每人一票,获得多数票的人就当选为总统了.在zookeeper集群中也是一样,每个节点都会投票,如

leader 选举机制

from: http://www.jasongj.com/2015/01/02/Kafka%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90/ 一种非常常用的选举leader的方式是"majority vote"("少数服从多数"),但Kafka并未采用这种方式.这种模式下,如果我们有2f+1个replica(包含leader和follower),那在commit之前必须保证有f+1个replica复制完消息,为了保证正确选出新的leader,

go任务调度6（etcd租约机制/自动过期）

对于实现分布式乐观锁非常重要.如果锁了,突然宕机了,锁是需要自动释放的.所以这锁在etcd里是需要生命期的.过期演示: package main import ( "context" "fmt" "go.etcd.io/etcd/clientv3" "time" ) func main() { var ( config clientv3.Config client *clientv3.Client err error leas

redis集群选举机制

概要当redis集群的主节点故障时,Sentinel集群将从剩余的从节点中选举一个新的主节点,有以下步骤: 故障节点主观下线故障节点客观下线Sentinel集群选举LeaderSentinel Leader决定新主节点选举过程1.主观下线Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常.如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包,则该redis节点被该Sentinel节点主观下线.