主从选举算法

① 搞懂Redis (八) - 哨兵机制

哨兵的核心功能是主节点的自动故障转移
下图是一个典型的哨兵集群监控的逻辑图

Redis Sentinel包含了若干个Sentinel 节点，这样做也带来了两个好处：

1、 对于节点的故障判断是由多个sentinel节点共同完成，这样可以有效地防止误判
2、即使个别sentinel节点不可用，整个sentinel集群依然是可用的

哨兵实现了以下功能：
1、监控：每个sentinel节点会对数据节点（Redis master/slave节点）和其余sentinel节点进行监控
2、通知：sentinel节点会将故障转移的结果通知给应用方
3、故障转移：实现slave晋升为master，并维护后续正确的主从关系
4、配置中心：在Redis sentinel模式中，客户端在初始化的时候连接的是sentinel节点集合，从中获取主节点信息

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置中心和通知功能，则需要在与客户端的交互中才能体现

1、原理
监控
sentinel节点需要监控master、slave以及其他sentinel节点的状态。这一过程是通过Redis的pubsub系统实现的。Redis sentinel一共有三个定时监控任务，完成对各个节点发现和监控：

主观/客观下线

主观下线

每个sentinel节点，每隔1s会对数据节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复时，sentinel节点会对该节点做失败判定，这叫主观下线

客观下线

客观下线，是指当大多数sentinel节点都认为master节点宕机了，那这个判定就是客观的，叫客观下线。
那大多数是指什么呢？ 其实就是分布式协调中的quorum判定啦，大多数就是指半数。 如哨兵数量是5，那大多数就是5/2+1=3个，哨兵数量是10大多数就是10/2+1=6个。
注：sentinel节点的数量至少为3个，否则不满足quorum判定条件

哨兵选举

如果发生了客观下线，那哨兵节点会选举出一个leader来进行实际的故障转移工作。Redis使用了Raft算法来实现哨兵领导者选举，大致思路如下：

故障转移
选举出的leader sentinel节点将负责故障转移，也就是进行master/slave节点的主从切换。故障转移，首先要从slave节点中筛选出一个作为新的master，主要考虑以下slave信息

注：Leader sentinel 节点，会从新的master节点那里得到一个configuration epoch，本质是个version版本号，每次主从切换的version号都必须是唯一的。其他的哨兵都是根据version来更新自己的master配置

② es源码笔记-7.x 选主流程

Discovery模块负责发现集群中的节点，以及选择主节点。ES支持多种不同Discovery类型选择，内置的实现有两种：Zen Discovery和Coordinator，其他的包括公有云平台亚马逊的EC2、谷歌的GCE等。

它假定所有节点都有一个唯一的ID，使用该ID对节点进行排序。任何时候的当前Leader都是参与集群的最高ID节点。该算法的优点是易于实现。但是，当拥有最大ID的节点处于不稳定状态的场景下会有问题。例如，Master负载过重而假死，集群拥有第二大ID的节点被选为新主，这时原来的Master恢复，再次被选为新主，然后又假死
ES 通过推迟选举，直到当前的 Master 失效来解决上述问题，只要当前主节点不挂掉，就不重新选主。但是容易产生脑裂（双主），为此，再通过“法定得票人数过半”解决脑裂问题

1、多数派原则：必须得到超过半数的选票才能成为master。
选出的leader一定拥有最新已提交数据：在raft中，数据更新的节点不会给数据旧的节点投选票，而当选需要多数派的选票，则当选人一定有最新已提交数据。在es中，version大的节点排序优先级高，同样用于保证这一点。

正确性论证：raft是一个被论证过正确性的算法，而ES的算法是一个没有经过论证的算法，只能在实践中发现问题，做bug fix，这是我认为最大的不同。

是否有选举周期term：raft引入了选举周期的概念，每轮选举term加1，保证了在同一个term下每个参与人只能投1票。ES在选举时没有term的概念，不能保证每轮每个节点只投一票。
选举的倾向性：raft中只要一个节点拥有最新的已提交的数据，则有机会选举成为master。在ES中，version相同时会按照NodeId排序，总是NodeId小的人优先级高。

2、Paxos算法
Paxos非常强大，尤其在什么时机，以及如何进行选举方面的灵活性比简单的Bully算法有很大的优势，因为在现实生活中，存在比网络连接异常更多的故障模式。但 Paxos 实现起来非常复杂

本篇只讨论内置的Zen Discovery

整体流程可以概括为：选举临时Master，如果本节点当选，则等待确立Master，如果其他节点当选，则尝试加入集群，然后启动节点失效探测器。

如果集群刚启动则参与选主，否则加入集群
org.elasticsearch.node.Node.start()

选举过程的实现位于 org.elasticsearch.discovery.zen.ZenDiscovery.findMaster() ,该函数查找当前集群的活跃 Master，或者从候选者中选择新的Master。如果选主成功，则返回选定的Master，否则返回空

上面选择临时主节点非常简单，
首先需要判断当前候选者人数是否达到法定人数，否则选主失败。

取列表中的最小值，比较函数通过compareNodes实现,只是对节点 ID 进行排序

选举出的临时Master有两种情况：该临时Master是本节点或非本节点。

（2）超时（默认为30秒，可配置）后还没有满足数量的join请求，则选举失败，需要进行新一轮选举。

超时后直接return，当非临时节点加入集群不成功时，重新发起选主流程
org.elasticsearch.discovery.zen.ZenDiscovery.innerJoinCluster()

（3）成功后发布新的clusterState。
实现如下：

submitStateUpdateTask最终通过TaskBatcher# submitTasks来提交任务。执行任务并发布集群状态的总体过程在 MasterService#runTasks 方法中实现。

（2）向Master发送加入请求，并等待回复。超时时间默认为1分钟（可配置），如果遇到异常，则默认重试3次（可配置）。这个步骤在joinElectedMaster方法中实现。

最终当选的Master会先发布集群状态，才确认客户的join请求，因此，joinElectedMaster返回代表收到了join请求的确认，并且已经收到了集群状态。所以如果返回不成功，则重新发起选主流程
（3）检查收到的集群状态中的Master节点如果为空，或者当选的Master不是之前选择的节点，则重新选举。

1、es通过主从模式以及发现机制保证节点之间的负载均衡，但是es使用量的急剧增加暴露了很多问题，例如，Zen的minimum_master_nodes设置经常配置错误，这会使群集更容易出现裂脑和丢失数据的风险
2、7.x以上版本Coordinator提供了安全的亚秒级的master选举时间，而Zen可能要花几秒钟来选择一个新的master
3、es的master挂了，数据节点在这区间还能对外提供服务吗？
参考
Elasticsearch分布式一致性原理剖析

③ DR与BDR有什么作用如何选举

DR和BDR的选举是根据优先级来确定的，优先级越大约有可能成为DR，如果优先级相同，那么就根据route-id的大小来选举，越大越有可能成为DR。
首先，所有路由器向外发送hello包的时候，每个路由器都认为自己是DR，这个时候的状态为init，当达到2-way状态时，已经是邻居关系，这个时候在你给我发的数据包中我能看见我自己的信息。这个时候谁的优先级大谁是DR，如果优先级相同就比较route-id。
如果主从关系确定后，一个新加入的路由器比DR优先级大，那么原有的DR还是DR.只有当DR挂掉后，原有的bdr会向外发送其优先级route-id和其他路由器对比，如果该BDR优先级高，那么继任DR的工作。
这里有一点需要明确：优先级都为0的时候，不能参与主从选举。drther都是优先级为0.
drther和dr通讯的组播地址是：224.0.0.6.
其余的都是224.0.0.6.

希望楼主好好看看卷一。
网络之路慢慢长，我们共勉吧

④ mysql group replication自动主从切换吗

mysql> show processlist\G
*************************** 1. row ***************************
Id: 3
User: system user
Host:
db: NULL
Command: Connect
Time: 2601
State: Slave has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 2. row ***************************
Id: 4
User: root
Host: localhost
db: NULL
Command: Query

⑤ 常见分布式集群选举机制总结

1，Zookeeper -- paxos

2，kafka -- zookeeper上创建节点

3，redis -- 哨兵模式

4，Eureka -- 相互复制

我们探讨这几个集群的选举机制，其实就是探讨它们的高可用性。如果集群中的某些节点挂了，如何保证可用性？这个问题是分布式系统面临的三大问题之一。

Zookeeper的leader选举机制，是这四种集群中最复杂的选举机制，同时也是这四种集群中最接近paxos算法的实现。相比于Zookeeper的选举机制，kafka集群、redis集群、Eureka集群的选举机制简单了许多。

Zookeeper的leader选举是Zookeeper实现数据一致性的关键，同时也存在一些问题。认清Zookeeper的优点与缺陷，对于我们使用好它还是很有必要的。

Zookeeper的选举机制有2个触发条件：集群启动阶段和集群运行阶段leader挂机。这2种场景下选举的流程基本一致，我们以集群运行阶段leader挂机为例来进行说明。leader挂机以后，重新选举leader，选举的流程如下：

1，Zookeeper集群中的follower检测到leader挂机，然后把自己的状态置为LOOKING，开始进行leader选举。

2，每台服务器选举自己为leader，然后把自己的选票通过广播通知其他服务器。

3，每台服务器接收来自其他服务器的选票，并进行合法性校验，主要有两点校验，选举轮次校验和服务器的状态的校验。

4，处理选票。每台服务器都会将自己的选票与其他服务器的选票进行PK，PK的规则如下：

第一个规则：首先进行ZXID的PK，大者获胜。

第二条规则：如果ZXID相等，则进行myid的PK，大者获胜。

经过PK以后，如果当前服务器PK失败，则会把自己的选票重新投给胜者，然后把更新后的选票通过广播通知其他服务器。

5，统计选票。根据超过半数的原则，每台服务器都会统计leader的选票，如果超过半数，则结束选举。

6，更新服务器状态。follower把自己的状态更新为FOLLOWING，leader把自己的状态更新为LEADING。

OK，这就是Zookeeper的leader选举机制。经过若干轮选举以后，Zookeeper集群继续对外提供服务。由于选票PK首先比较的是ZXID，所以Zookeeper能够保证leader的数据是最新的。

kafka集群是如何保证高可用性的呢？

kafka通过Zookeeper管理集群配置、选举leader、consumer group发生变化时进行rebalance。

那么我要问了，kafka是如何选举leader的呢？

概括来说，Kafka选举leader的过程是这样的：kafka的所有broker，在Zookeeper的/controller路径下创建临时节点，成功创建的那个broker就会成为leader，其他的broker就会成为follower。

当leader挂机时，临时节点会被删除，这是其他节点通过Zookeeper的watch机制，会监听到leader的变化，然后所有的follower会再次进行leader选举。

kafka的选举其实就是创建临时节点，这和Zookeeper分布式锁的实现原理基本相同。

redis主从切换和redis集群的理解。

要注意，主从切换默认只有一个master，但是对于多个master的集群，没有主从切换的说法。

redis没有类似Zookeeper的选举机制。redis的master挂掉以后，redis集群是通过主从切换来保证高可用性的。

redis主从切换有2种方式：手动切换和自动切换。

这里我们讨论自动切换，redis主从自动切换需要哨兵模式的支持，哨兵模式简单来说就是：监控master和slave，在master出现故障的时候，自动将slave切换成master，master恢复以后，作为新master的slave对外提供服务。

准确的来说，Eureka集群中的各节点之间不存在主从关系。Eureka集群中的节点的关系是对等的，其他3种集群则都存在主从关系，这是Eureka集群的一个特色。

Eureka集群的各个server之间通过相互注册的方式来实现集群的高可用性。数据同步的方式是增量备份，这样可以保证每个server都是最新最全的数据。从而保证集群的高可用性。这样即使某个server挂了，集群还可以对外提供服务。

Eureka有一个配置项：eureka.client.fetch-register，是否从Eureka server获取注册信息。如果我们是Eureka集群，那么该项配置为true。这样Eureka server直接就可以相互注册。

OK，这篇文章只是对4种集群的选举机制进行了一个概括性的介绍，具体细节还是很复杂的。之前有文章重点分析过Zookeeper的leader选举，后续还会另起文章分析其他几种集群的选举机制，到时候我们再进行更深入的讲解。

⑥ ospf多路访问链路中的主从关系

DR(指定路由器)与BDR（备用指定路由器）说是主从关系不确切的，他们的关系应该是主力与替补的关系。
OSPF协议用的是比较高级的SPF算法，因为此协议为了好管理把端口们划分为一个个单位，称为域（area）。因为SPF算法很占用路由器的内存空间并且OSPF网络环境复杂，为了节省空间，每个域里只要有1个路由器知道外面的情况的就可以了，这个路由器就叫DR了。域里其他的路由器只要知道域内情况就可以了。
可是谁又能保证DR不会坏呢？所以要有个替补，这就是BDR了。

DR与BDR的选举是依靠的人为设置的路由优先级（不设置一般默认是100），当然优先级也能设为0，这样这个路由器永远不能被选举成DR或BDR。
OSPF大致是4类网络，点到点与点到多点这两类需要的认为指定DR/BDR，因为这两类多用在网络分支上，方便管理。
广播网络与NBMA这两类则需要选举DR/BDR。这两类网络搭建好后，路由间会依靠一种LSA自动选举出来DR与BDR。这两类网络主要用于主干网络，所以事先要谋划计算好，轻易不能改动。过程中，如果DR坏了，BDR自动变成DR，然后又有新的BDR被选举出来。

用命令找DR很简单 show ip route就可以的 DR/BDR里可以看到他们与其他路由都添加邻居，并且要复杂的多

⑦ redis主从和哨兵

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；
b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

c,查看状态：info replication
d,断开主从复制：在slave节点，执行6380:>slaveof no one
e,断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379
f,数据较重要的节点，主从复制时使用密码验证： requirepass
e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
b)主从复制主节点的写能力单机，能力有限
c)单机节点的存储能力也有限

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
b)其它的节点成为新主节点的从节点，并从新节点复制数据；
c)需要人工干预，无法实现高可用。

1. 为什么要有哨兵机制？

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

1. 将slave-1脱离原从节点，升级主节点，

d) 故障转移后的redis sentinel的拓扑结构图

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

1. 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：

A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：

修改 requirepass 12345678，注释掉#bind 127.0.0.1

B) 从节点redis6380.conf和redis6381.conf: 配置都一样

修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,

加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379

2. redis sentinel哨兵机制核心配置 (也是3个节点)：

将三个文件的端口改成: 26379 26380 26381

然后：sentinel monitor mymaster 192.168.152.128 6379 2 //监听主节点6379

三个配置除端口外，其它一样。

3. 哨兵其它的配置 ：只要修改每个sentinel.conf的这段配置即可：

sentinel monitor mymaster 192.168.152.128 6379 2

//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码

sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA **180000 **//故障转移超时时间180s，

a,如果转移超时失败，下次转移时时间为之前的2倍；

b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败

c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

4. 启动redis服务和sentinel服务:

a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件

b)启动主从复制服务，先启动主再启动从

主：./redis-server conf/redis6379.conf &

从：

./redis-server conf/redis6380.conf &

./redis-server conf/redis6381.conf &

c）启动sentinel服务:

./redis-sentinel conf/sentinel_26381.conf &

到此服务全部启动完毕

连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点

5. 测试： kill -9 6379 杀掉6379的redis服务

可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点

重新启动6379以后变为6380的从节点

看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:进入6380>info replication 可以看到role:master

打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2

打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380

注意：生产环境建议让redis Sentinel部署到不同的物理机上。

a，sentinel节点应部署在多台物理机（线上环境）

b，至少三个且奇数个sentinel节点

c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点

sentinel参考资料：
redis sentinel的机制与用法一： https://segmentfault.com/a/1190000002680804

redis sentinel的机制与用法二： https://segmentfault.com/a/1190000002685515

⑧ ES原理之选主流程

分布式系统的集群方式大致可以分为主从模式（Master-Slave）和无主模式。

常用的选举算法有比较简单的Bully算法和复杂而强大的Paxos算法。

每个节点有一个唯一ID，然后对集群中所有的节点ID进行排序，选取其中最小的ID所属的节点作为Master。
Bully算法的问题： 假设当前Master因为负载过重而假死，然后ID第二大的被选举为新的Master，这时旧的Master恢复然后又被选举为Master然后又会因为负载过重而假死......

Paxos实现起来非常复杂,但非常强大，尤其在什么时机,以及如何进行选举方面的灵活性比简单的Bully算法有很大的优势，因为在现实生活中，存在比网络链接异常更多的故障模式。
ES使用的是Bully算法，并对其做了一些优化：

⑨ ospf选举主从与选举DR的联系

两者间没有联系
1，先说主从吧，所有接口网路类型都有，是决定邻接关系建立后谁先发送update的，默认router ID 大的为主，先发update，在DBD包里面有个字段来选举主从
2，DR,BDR，只在MA网络中有，用来决定是谁来做指定路由器，Dother间保持邻居关系，只和DR为邻接
其实，他们两个在ospf邻接建立过程中式发生在不同的状态下的
我也在学习中，一起进步吧

⑩ mysql group replication单主集群jdbc怎么配置

mysql group replication单主集群jdbc怎么配置
主从 就是 读写分离，主数据库负责写服务器，实时同步到从数据库（硬件和网络不同情况会有不同时间的延迟，阿里云主从数据库延迟几十毫秒）， 从数据库负责提供读取服务器，创建只读账号 不能创建表和写入数据。

双主集群 没听过，你说的是不是Mysql的MMM架构，当一个主从挂掉了 自动切换到另外一个主从服务器，当这个恢复后自动把增加的数据拷贝 回来 并提供服务