【各类选举机制】

各类选举机制

    • Redis选举
    • Mysql选举
    • Kafka选举机制
    • Paxos算法
    • Raft算法
    • ZAB算法

Redis选举

1.slave priority:选择优先级slave-priority最大的从节点作为主节点,如不存在则继续。 按照slave优先级进行排序,slave priority越低,优先级就越高。
2.replica offset:选择复制偏移量(数据写入量的字节,记录写了多少数据。主服务器会把偏移量同步给从服务器,当主从的偏移量一致,则数据是完全同步)最大的从节点作为主节点,如不存在则继续。如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高。
3.run id:如果上面两个条件都相同,那么选择一个run id比较小的那个slave。(redis每次启动的时候生成随机的runid作为redis的标识)

Mysql选举

一主两从的环境,如果主库挂了,如何选举一个从库作为主库的切换过程(整个过程快的话大概1-5秒):

1.修改主库密码,断开所有连接

(1)改密码,不能影响已有的连接,记得要把已有的连接都kill掉。

(2)flush table with read lock

(3)开启参数super_read_only=on

(4)通过防火墙把3306端口封住

2.判断S1和S2同步情况, show slave status;

当Master_Log_File = Relay_Master_Log_File &&  Read_Master_Log_Pos = Exec_Master_Log_Pos 表示从库与主库同步完成。
 
如果Master_Log_File = Relay_Master_Log_File,但是Read_Master_Log_Pos > Exec_Master_Log_Pos,并且sql_thread的状态是 Connecting,表示relay-log还没有重放完成,大概等待2-5s也就会同步完成。

3.选举新库

4.写流量放在新主上

Kafka选举机制

1.Controller选举机制:选举的过程是集群中每个broker都会尝试在zookeeper上创建一个 /controller 临时节点,zookeeper会保证有且仅有一个broker能创建成功,这个broker就会成为集群的总控器controller

2.Partition副本选举Leader机制:controller会从ISR列表里挑第一个broker作为leader(第一个broker最先放进ISR列表,可能是同步数据最多的副本),如果参数unclean.leader.election.enable为true,代表在ISR列表里所有副本都挂了的时候可以在ISR列表以外的副本中选leader

Paxos算法

**Proposer:**这种角色的职责是提出提案
Acceptor: 它的职责是对提案进行表决,同意或者拒绝
Learner: 它不参与选举过程,只获取选举的最终结果

第一阶段(Prepare阶段):

(1)Proposer先发起选举,给Acceptor发送提案

(2)Acceptor同意事务号大的提案并返回给Proposer

(3)Proposer收到反馈后进入第二阶段。

第二阶段(Accept阶段):

(1)Proposer给Acceptor发送成为Leader的请求,

(2)Acceptor收到命令后最终同意事务号大的提案并反馈给Proposer

(3)然后进入第三阶段(Learn阶段)

第三阶段(Learn阶段):此时选举已经产生结果,Proposer成为Leader,然后将结果发送给Learner。

Raft算法

Raft是Paxos的简单版本 , 没有事务ID,每个节点只有一张投票,先到先得

Leader,即主节点,同一时刻只有一个 Leader,负责协调和管理其他节点;
Candidate,即候选者,每一个节点都可以成为 Candidate,节点在该角色下才可以被选为新的 Leader;
Follower,Leader 的跟随者,不可以发起选举。

选举流程

  1. 初始化时,所有节点均为 Follower 状态。
  2. 开始选主时,所有节点的状态由 Follower 转化为 Candidate,并向其他节点发送选举请求。
  3. 其他节点根据接收到的选举请求的先后顺序,回复是否同意成为主。这里需要注意的是,在每一轮选举中,一个节点只能投出一张票。
  4. 若发起选举请求的节点获得超过一半的投票,则成为主节点,其状态转化为 Leader,其他节点的状态则由 Candidate 降为 Follower。Leader 节点与 Follower 节点之间会定期发送心跳包,以检测主节点是否活着。
  5. 当 Leader 节点的任期到了,即发现其他服务器开始下一轮选主周期时,Leader 节点的状态由 Leader 降级为 Follower,进入新一轮选主

ZAB算法

ZAB 算法本质上就是Paxos算法,增加了通过节点 ID 和数据 ID 作为参考进行选主,节点 ID 和数据 ID 越大,表示数据越新,优先成为主。

Leader,主节点;
Follower,跟随者节点;
Observer,观察者,无投票权。

第一步:当系统刚启动时,3 个服务器当前投票均为第一轮投票,即 epoch=1,且 zxID 均为 0。此时每个服务器都推选自己,并将选票信息 广播出去。

第二步:根据判断规则,由于 3 个 Server 的 epoch、zxID 都相同,因此比较 server_id,较大者即为推选对象,因此 Server 1 和 Server 2 将 vote_id 改为 3,更新自己的投票箱并重新广播自己的投票。

第三步:此时系统内所有服务器都推选了 Server 3,因此 Server 3 当选 Leader,处于 Leading 状态,向其他服务器发送心跳包并维护连接;Server1 和 Server2 处于 Following 状态。

你可能感兴趣的:(java,java,数据库,分布式)