宜春网站制作,深圳十大电子厂排名,北京百度科技有限公司电话,企业宣传海报设计制作摘要
当我们使用主从复制出现的问题#xff1a;手动故障转移#xff1a;写能力和存储能力受限#xff1a;主从复制 -master 宕机故障处理。
主从切换技术的方法是#xff1a;当主服务器宕机后#xff0c;需要手动把一台从服务器切换为主服务器#xff0c;这就需要人工干…摘要
当我们使用主从复制出现的问题手动故障转移写能力和存储能力受限主从复制 -master 宕机故障处理。
主从切换技术的方法是当主服务器宕机后需要手动把一台从服务器切换为主服务器这就需要人工干预费事费力还会造成一段时间内服务不可用。这不是一种推荐的方式更多时候我们优先考虑哨兵模式。 哨兵模式是一种特殊的模式首先Redis提供了哨兵的命令哨兵是一个独立的进程作为进程它会独立运行。其原理是哨兵通过发送命令等待Redis服务器响应从而监控运行的多个Redis实例。
哨兵主要有两个作用 通过发送命令让Redis服务器返回监控其运行状态包括主服务器和从服务器。 当哨兵监测到master宕机会自动将slave切换成master然后通过发布订阅模式通知其他的从服务器修改配置文件让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控可能会出现问题为此我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控这样就形成了多哨兵模式。
哨兵模式(raft)与Zookeeper模式zab选主的总结
Redis中的Sentinel选主相对来说更简单因为不涉及事务状态的一致性Sentinel选主是基于raft协议Zookeeper则基于Zab协议二者都是收到半数的选票就选举成功Sentinel投票发消息主要内容是Sentinel id和配置纪元Zookeeper则是 zxid和 sidSentinel谁先来找他投票他就投谁Zookeeper中则是要细细检查比较一番检查内容包括epoch和节点状态检查完毕后再跟自己的投票进行pk进而看需不需要更新自己的投票若是需要则自己的投票也要广播出去
故障切换failover的过程。
假设主服务器宕机哨兵1先检测到这个结果系统并不会马上进行failover过程仅仅是哨兵1主观的认为主服务器不可用这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用并且数量达到一定值时那么哨兵之间就会进行一次投票与Zookeeper的过半机制有什么不同 投票的结果由一个哨兵发起进行failover操作。切换成功后就会通过发布订阅模式让各个哨兵把自己监控的从服务器实现切换主机这个过程称为客观下线。这样对于客户端而言一切都是透明的。
架构说明 多个sentinel 发现并确认master有问题。选举出一个sentinel作为领导怎么选举选出一个slave作为master通知其余的slave成为新的master的slave通知客户端主从变化等待老的master复活成新的master的slave
领导者选举 只需要一个sentinel节点完成故障转移 通过sentinel is - master -down -by-addr 命令都希望成为领导者 -1. 每个主观下线都Sentitle 节点向其他Sentinel节点发送命令要求将它设置为领导者 -2. 收到命令对Sentinel节点如果没有同一通过其他Sentinel节点发送的命令那么就将同一该请求否则拒绝 -3. 如果该Sentinel节点发现直接的票数已经超过Sentinel集合半数且超过quorum那么它将成为领导者 -4. 如果此过程由多个Sentinel节点成为领导者那么将来等待一段时间重新进行选举
需要说明的问题
尽可能在不同物理机上和同一个网络部署Redis sentinel的所有节点Redis sentinel中的sentinel节点个数应该大于等于3且最好是奇数。节点数多可以保证高可用Redis sentinel中的数据节点和普通数据节点没有区别。每个sentinel节点在本质上还是一个Redis实例只不过和Redis数据节点不同的是其主要作用是监控Redis数据节点客户端初始化时连接的是sentinel节点集合不再是具体的Redis节点但sentinel只是配置中心不是代理。
哨兵模式与Zookeeper选举的异同点
zk 选举
假设有两个server
(1) 发起投票
每个Server发出一个投票投给自己。由于是初始情况Server1和Server2都会将自己作为Leader服务器来进行投票每次投票会包含所推举的服务器的myid和ZXID使用(myid, ZXID)来表示此时Server1的投票为(1, 0)Server2的投票为(2, 0)然后各自将这个投票发给集群中其他机器。
(2) 接受投票
来自各个服务器的投票。集群的每个服务器收到投票后首先判断该投票的有效性如检查是否是本轮投票通过logicalclock确定是否轮次比当前大、是否来自LOOKING状态的服务器。
(3) 处理投票。
轮次比较
如果轮次比当前大则清空本地投票箱recvset并将自己和收到的投票PK谁大投谁,并广播。如果轮次跟当前一样则比较本地投票箱里产生的leader和接受到的投票信息谁大投谁如果更新了就广播。如果轮次比当前小则忽略
选票PK
1、优先检查ZXID。ZXID比较大的服务器胜出。
2、如果ZXID相同那么就比较myid。myid较大的服务器胜出。
例如对于Server1而言它的投票是(1, 0)接收Server2的投票为(2, 0)首先会比较两者的ZXID均为0再比较myid此时Server2的myid最大于是更新自己的投票为(2, 0)然后重新投票对于Server2而言其无须更新自己的投票只是再次向集群中所有机器发出上一次投票信息即可。
(4) 统计投票。
每次投票后服务器都会统计投票信息判断是否已经有过半机器接受到相同的投票信息对于Server1、Server2而言都统计出集群中已经有两台机器接受了(2, 0)的投票信息此时便认为已经选出了Leader。
(5) 改变服务器状态。
一旦确定了Leader每个服务器就会更新自己的状态如果是Follower那么就变更为FOLLOWING如果是Leader就变更为LEADING。
redis 选举
如果需要从redis集群选举一个节点为主节点首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader当一个Sentinel节点确认redis集群的主节点主观下线后会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求则同意该请求(选举票数1)否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/21的最大值)则该Sentinel节点选举为Leader否则重新进行选举。
当Sentinel集群选举出Sentinel Leader后由Sentinel Leader从redis从节点中选择一个redis节点作为主节点
过滤故障的节点选择优先级slave-priority最大的从节点作为主节点如不存在则继续选择复制偏移量数据写入量的字节记录写了多少数据。主服务器会把偏移量同步给从服务器当主从的偏移量一致则数据是完全同步最大的从节点作为主节点如不存在则继续选择runidredis每次启动的时候生成随机的runid作为redis的标识最小的从节点作为主节点
Redis选举领头Sentinelraft算法
Sentinel是Redis实现高可用的保证。Sentinel系统作用就是监视Redis服务器集群它可以不停的获得redis集群状态当一个主节点挂了故障转移操作会在从节点中选出一个新的主节点这里故障转移就是由Sentinel来主导完成的。不要把Sentinel想的太复杂它其实就是一个特殊工作模式的Redis服务器而已Redis是集群部署的这里的Sentinel也是要集群部署的要是非单点部署你的Sentinel挂了此时的Redis集群就GG了。接着上边说当主服务器节点挂了Sentinel系统就会选出一个领头的Sentinel来完成故障转移工作。选举规则如下: - 监视这个挂了的主节点的所有Sentinel都有被选举为领头的资格
每进行一次选举不论是否成功配置纪元1配置纪元就是个计数器每个Sentinel在每个配置纪元中有且仅有一次选举机会一旦选好了该节点认为的主节点在这个纪元内不可以再更改每个发现服务器挂了的Sentinel都会配置纪元1并投自己一票接着发消息要求其他Sentinel设置自己为领头人1每个Sentinel都想成为领头的每个Sentinel会将最先发来请求领头的节点设为自己的领头节点并发送回复谁先来我选谁当源Sentinel收到回复并且回复中的配置纪元和自己的一致且领头Id是自己的Sentinel Id时表明目标Sentinel已经将自己设为领头在一个配置纪元内当某个Sentinel收到半数以上的同意回复时它就是领头的了如果在给定时间内没有被成功选举的Sentinel那么过段时间发起新的选举
选举领头Sentinel的过程和规则大概就如上所述需要注意的是只有集群出现节点挂了才需要选举出领头Sentinel平时每个Sentinel还是平等身份~
Zookeeper选举
Zookeeper是一个很强的分布式数据一致性解决方案比如dubbo中的注册中心就使用的Zookeeper。当然这也是集群部署的但是它没有采用传统的Master/Slave结构而是引入了Leader、Follwer和Observer。Leader和Follower类似于Master/Slave新增的Observer作用仅仅只是增加集群的读性能它不参与Leader的选举。
节点的状态有以下几种
LOOKING: 节点正处于选主状态不对外提供服务直至选主结束FOLLOWING: 作为系统的从节点接受主节点的更新并写入本地日志LEADING: 作为系统主节点接受客户端更新写入本地日志并复制到从节点
Zookeeper的状态同步是基于Zab协议实现的Zab协议有两种模式它们分别是崩溃恢复选主和消息广播同步。当服务启动或者在Leader崩溃后Zab就进入了恢复模式当Leader被选举出来且超过一半机器完成了和 leader的状态同步以后恢复模式就结束了。
首先明确几个概念 - Sid服务器id
Zxid服务器的事务id数据越新zxid越大zxid的高32位是epoch低32位是zpoch内的自增id由0开始。每次选出新的Leaderepoch会递增同时zxid的低32位清0。
整个选主流程如下
状态变更。服务器启动的时候每个server的状态时Looking如果是leader挂掉后进入选举那么余下的非Observer的Server就会将自己的服务器状态变更为Looking然后开始进入Leader的选举状态发起投票。每个server会产生一个sidzxid的投票系统初始化的时候zxid都是0如果是运行期间每个server的zxid可能都不同这取决于最后一次更新的数据。将投票发送给集群中的所有机器接收并检查投票。server收到投票后会先检查是否是本轮投票是否来自looking状态的server处理投票。对自己的投票和接收到的投票进行PK 先检查zxid较大的优先为leader如果zxid一样sid较大的为leader根据PK结果更新自己的投票再次发送自己的投票 统计投票。每次投票后服务器统计投票信息如果有过半机器接收到相同的投票那么leader产生如果否那么进行下一轮投票改变server状态。一旦确定了Leaderserver会更新自己的状态为Following或者是Leading。选举结束。
我们要保证选主完成后原来的主节点已经提交的事务继续完成提交原主节点只是提出而没提交的事务要抛弃。这也是为什么倾向于选zxid最大的从节点为主节点因为它上边的事务最新最与原主节点保持一致。
哨兵模式(raft)与Zookeeper模式zab选主的总结
Redis中的Sentinel选主相对来说更简单因为不涉及事务状态的一致性Sentinel选主是基于raft协议Zookeeper则基于Zab协议二者都是收到半数的选票就选举成功Sentinel投票发消息主要内容是Sentinel id和配置纪元Zookeeper则是 zxid和 sidSentinel谁先来找他投票他就投谁Zookeeper中则是要细细检查比较一番检查内容包括epoch和节点状态检查完毕后再跟自己的投票进行pk进而看需不需要更新自己的投票若是需要则自己的投票也要广播出去
