在大数据分布式存储上,Redis数据库的性能也是得到认可的,作为内存数据库,在集群环境运行时,尤其需要保证稳定可靠,减少故障发生造成的损失。今天的大数据开发学习分享,我们就主要来讲讲Redis集群复制和故障转移这个部分。
一、集群的问题
1.当某个主节点宕机后,对应的槽位没有节点承担,整个集群处于失败状态,不可用,怎么办?
2.如何判断某个主节点是否真正的岩机?
3.如果从某个主节点的所有从节点中选举出一个合适的节点作为新的主节点?
二、集群复制
1.复制原理与单节点的主从复制一样
2.从节点也是运行在集群模式下,所以安装主节点的方式配置即可
3.通过cluster meet把此节点添加到集群中去
4.在即将成为从节点的节点命令行执行cluster replicate<nodeid>,即把此节点设置为nodejd对应节点的从节点
三、故障检测
1.集群中所有节点都会向其它节点发送PING消息,当在规定的时间内,没有收到对应的PONG消息,就把此节点标记为疑似下线
2.在发送的PING消息里面,会带着当前集群和节点的信息;通过这种方式,即可检测节点的存活,又能维护集群信息的统一性,不过有一定的时延
3.疑似下线不是真的下线,只有满足以下条件才是真的下线
主节点并且是被分配了slot槽位的主节点中有超过一半的节点都认为此节点疑似下线,才能真的下线
4.当某个节点通过消息得知有一个节点的疑似下线投票已经超过集群一半的时候,会发送一个标识此节点下线的广播消息
5.其它节点收到某节点已经下线的广播后,把自己内部的集群维护信息也修改为节点已下线状态
四、故障转移
1.从所有的从节点里面选举出一个新的主
2.选举出的新主会执行slave of no one把自己的状态从slave变成master
3.撤销已下线的主节点的槽指派,并把这些槽位重新指派给自己
4.新的主节点向集群广播一条PONG消息,通过这个消息告诉所有集群节点:自己已经变成了主节点,接管了原来的主节点
5.新的主节点开始接收和处理与自己槽位相关的命令请求
五、如何从所有的从节点中选举产生新的主节点
1.每一次选举,配置纪元都会加一,从0开始
2.所有具备投票资格的节点在一次选举里面只能投一次票,并且是先到先得
条件一:主节点
条件二:被分配了槽位
3.当从节点发现自己所属的主节点宕机后,从节点会向集群广播一条CLUSTERMSGTYPEFAILOVERAUTHREQUEST的消息,要求具备投票资格的节点给自己投票
4.如果收到消息的节点具备资格,并且没有投过别的节点,则返回一条CLUSTERMSGTYPEFAILOVERAUTHACK消息,表示自己投票了
5.发起投票的节点计算自己收到的投票数,如果超过了一半,则自己变成主节点,执行故障转移操作
6.如果没有节点满足一半的要求,则配置纪元加一,重新进行选举
关于大数据开发学习,Redis集群复制和故障转移,以上就为大家做了粗略的介绍了。Redis的集群和故障转移这部分,其实深挖下来需要理解的东西很多,可以多参考源码进行理解。