redis集群选举机制

概要
当redis集群的主节点故障时,Sentinel集群将从剩余的从节点中选举一个新的主节点,有以下步骤:

故障节点主观下线
故障节点客观下线
Sentinel集群选举Leader
Sentinel Leader决定新主节点
选举过程
1、主观下线
Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包,则该redis节点被该Sentinel节点主观下线。

2、客观下线
当节点被一个Sentinel节点记为主观下线时,并不意味着该节点肯定故障了,还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。

该Sentinel节点会询问其他Sentinel节点,如果Sentinel集群中超过quorum数量的Sentinel节点认为该redis节点主观下线,则该redis客观下线。

如果客观下线的redis节点是从节点或者是Sentinel节点,则操作到此为止,没有后续的操作了;如果客观下线的redis节点为主节点,则开始故障转移,从从节点中选举一个节点升级为主节点。

3、Sentinel集群选举Leader
如果需要从redis集群选举一个节点为主节点,首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader,当一个Sentinel节点确认redis集群的主节点主观下线后,会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求,则同意该请求(选举票数+1),否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值),则该Sentinel节点选举为Leader;否则重新进行选举。

4、Sentinel Leader决定新主节点
当Sentinel集群选举出Sentinel Leader后,由Sentinel Leader从redis从节点中选择一个redis节点作为主节点:

过滤故障的节点
选择优先级slave-priority最大的从节点作为主节点,如不存在则继续
选择复制偏移量(数据写入量的字节,记录写了多少数据。主服务器会把偏移量同步给从服务器,当主从的偏移量一致,则数据是完全同步)最大的从节点作为主节点,如不存在则继续
选择runid(redis每次启动的时候生成随机的runid作为redis的标识)最小的从节点作为主节点
存在
不存在
存在
不存在
从节点列表
过滤故障节点
slave-priority最大的从节点
升级主节点
复制偏移量最大的从节点
升级主节点
runid最小的从节点升级主节点
为什么Sentinel集群至少3节点
一个Sentinel节选举成为Leader的最低票数为quorum和Sentinel节点数/2+1的最大值,如果Sentinel集群只有2个Sentinel节点,则

Sentinel节点数/2 + 1
= 2/2 + 1
= 2
1
2
3
即Leader最低票数至少为2,当该Sentinel集群中由一个Sentinel节点故障后,仅剩的一个Sentinel节点是永远无法成为Leader。

也可以由此公式可以推导出,Sentinel集群允许1个Sentinel节点故障则需要3个节点的集群;允许2个节点故障则需要5个节点集群。

原文地址:https://blog.51cto.com/youling87/2481899

时间: 2024-10-07 12:11:29

redis集群选举机制的相关文章

redis集群选举

redis集群特点 所有的redis节点彼此互联,内部使用二进制协议优化带宽和传输速度 节点的fail是通过集群中超过半数的节点监测失效时才生效 客户端与redis节点直连不需要proxy,链接集群中任意一个节点即可 redis-cluster吧所有的节点映射到[0-16383](hash 槽)上,cluster负责维护node 集群容错和选举 (1)节点容错选举时所有的master进行选举,如果半数以上master通讯的节点挂掉,就认为master集群挂掉 (2)如果任意集群的master挂掉

Redis集群搭建及选举原理

redis集群简述 哨兵模式中如果主从中master宕机了,是通过哨兵来选举出新的master,在这个选举切换主从的过程,整个redis服务是不可用的.而且哨兵模式中只有一个主节点对外提供服务,因此没法支持更高的并发.而且当个主节点的内存设置也不宜过大.否则会导致持久化文件过大,影响数据恢复或主从同步的效率. redis集群是由一系列的主从节点群组成的分布式服务器群,它具有复制.高可用和分片特性.Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能.需要将每个节点设置成集群

Redis集群,备份,哨兵机制

原文:https://blog.csdn.net/zy345293721/article/details/87536144 1.集群        先来简单了解下redis中提供的集群策略, 虽然redis有持久化功能能够保障redis服务器宕机也能恢复并且只有少量的数据损失,但是由于所有数据在一台服务器上,如果这台服务器出现硬盘故障,那就算是有备份也仍然不可避免数据丢失的问题.       在实际生产环境中,我们不可能只使用一台redis服务器作为我们的缓存服务器,必须要多台实现集群,避免出现

Redis集群节点的选举(实验)

Redis集群节点的选举: 当master挂掉之后,就会在该集群中的slave中选取一个来代替mater角色, 从而保证redis集群slot的完整性. 如果其中一个mster和它的slave都挂掉后,会导致slot不完整,整个集群都会挂掉. 集群节点信息: 192.168.2.200:6379> cluster nodes 3ff3a74f9dc41f8bc635ab845ad76bf77ffb0f69 192.168.2.201:6379 master - 0 1527145806504 5

Redis集群分片原理及选举流程

Redis集群分片原理及选举流程 集群分片模式 如果Redis只用复制功能做主从,那么当数据量巨大的情况下,单机情况下可能已经承受不下一份数据,更不用说是主从都要各自保存一份完整的数据.在这种情况下,数据分片是一个非常好的解决办法. Redis的Cluster正是用于解决该问题.它主要提供两个功能: 自动对数据分片,落到各个节点上 即使集群部分节点失效或者连接不上,依然可以继续处理命令 对于第二点,它的功能有点类似于Sentienl的故障转移,在这里不细说.下面详细了解下Redis的槽位分片原理

Redis集群的高可用测试(含Jedis客户端的使用)

Redis集群的使用测试(Jedis客户端的使用) 1.  Jedis客户端建议升级到最新版(当前为2.7.3),这样对3.0.x集群有比较好的支持. https://github.com/xetorthio/jedis http://mvnrepository.com/artifact/redis.clients/jedis 2.  直接在Java代码中链接Redis集群: // 数据库链接池配置 JedisPoolConfig config = new JedisPoolConfig();

redis 集群配置实战

最近研究Redis-cluster,正好搭建了一个环境,遇到了很多坑,系统的总结下,等到redis3 release出来后,换掉memCache 集群. 一:关于redis cluster 1:redis cluster的现状 reids-cluster计划在redis3.0中推出,可以看作者antirez的声明:http://antirez.com/news/49 (ps:跳票了好久,今年貌似加快速度了),目前的最新版本是redis3 beta2(2.9.51). 作者的目标:Redis Cl

Redis集群~StackExchange.redis连接Twemproxy代理服务器

回到目录 本文是Redis集群系列的一篇文章,主要介绍使用StackExchange.Redis进行Twemproxy(文中简称TW)代理服务的连接过程,事务上,对于TW来说,我们需要理解一下它的物理架构,它类似于Nugix,主要实现的是请求转发,但它还有一个重要的功能,那就是自动分片,这对于大数据是很必要的,你的服务器需要横向扩展时,不需要告诉客户端,这是一种很理解化的设计模式,当然,也对于Redis来说,在配置TW之后,是可以被全美支持的! 关于tw和Redis集群的设计图 关于StackE

Redis集群战法整理

单机及集群搭建 http://www.codeceo.com/article/distributed-caching-redis-server.html 主从复制设置 Redis服务器复制(主—从配置) Redis支持主从同步,即,每次主服务器修改,从服务器得到通知,并自动同步.大多复制用于读取(但不能写)扩展和数据冗余和服务器故障转移.设置两个Redis实例(在相同或不同服务器上的两个服务),然后配置其中之一作为从站.为了让Redis服务器实例是另一台服务器的从属,可以这样更改配置文件: 找到