详解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最低票数(quorumSentinel节点数/2+1的最大值),则该Sentinel节点选举为Leader;否则重新进行选举。

4、Sentinel Leader决定新主节点

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

  • 过滤故障的节点
  • 选择优先级slave-priority最大的从节点作为主节点,如不存在则继续
  • 选择复制偏移量(数据写入量的字节,记录写了多少数据。主服务器会把偏移量同步给从服务器,当主从的偏移量一致,则数据是完全同步)最大的从节点作为主节点,如不存在则继续
  • 选择runid(redis每次启动的时候生成随机的runid作为redis的标识)最小的从节点作为主节点

为什么Sentinel集群至少3节点

一个Sentinel节选举成为Leader的最低票数为quorumSentinel节点数/2+1的最大值,如果Sentinel集群只有2个Sentinel节点,则

Sentinel节点数/2 + 1
= 2/2 + 1
= 2

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

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

到此这篇关于详解redis集群选举机制的文章就介绍到这了,更多相关redis集群选举机制内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详细分析Redis集群故障

    故障表象: 业务层面显示提示查询redis失败 集群组成: 3主3从,每个节点的数据有8GB 机器分布: 在同一个机架中, xx.x.xxx.199 xx.x.xxx.200 xx.x.xxx.201 redis-server进程状态: 通过命令ps -eo pid,lstart | grep $pid, 发现进程已经持续运行了3个月 发生故障前集群的节点状态: xx.x.xxx.200:8371(bedab2c537fe94f8c0363ac4ae97d56832316e65) master

  • Windows环境部署Redis集群

    一.准备文件 1.下载Redis for windows 的最新版本 下载地址:https://github.com/MSOpenTech/redis/releases 安装到 c:\Redis 目录下(Redis-x64-3.2.100.msi <Windows服务版>) 2.下载 RubyInstaller 下载地址:http://rubyinstaller.org/downloads/ 安装时,勾选:(所使用版本rubyinstaller-2.3.1-x64.exe) Install T

  • redis集群搭建教程及遇到的问题处理

    这里,在一个Linux虚拟机上搭建6个节点的redis伪集群,思路很简单,一台虚拟机上开启6个redis实例,每个redis实例有自己的端口.这样的话,相当于模拟出了6台机器了,然后在以这6个实例组建redis集群就可以了. 前提:redis已经安装,目录为/usr/local/redis-4.0.1 如不会,可以参考一下文章  windows下安装redis    Linux下安装redis redis集群是用的ruby脚本,所以要想执行该脚本,需要ruby环境..对应redis的源码src目

  • Redis集群搭建全记录

    Redis集群是一个提供在多个Redis节点间共享数据的程序集. Redis集群中不支持处理多个keys的命令. Redis集群通过分区来提供一定程度的可用性.在某个节点宕机或者不可用的时候可以继续处理命令. Redis集群数据分片 在Redis集群中,使用数据分片(sharding)而不是一致性hash(consistency hashing)来实现,一个Redis集群包含16384个哈希槽(hash slot),数据库中的每个键都存在这些哈希槽中的某一个,通过CRC16校验后对16384取模

  • Redis cluster集群的介绍

    1.前言 Redis集群模式主要有2种: 主从集群.分布式集群. 前者主要是为了高可用或是读写分离,后者为了更好的存储数据,负载均衡. redis集群提供了以下两个好处 1.将数据自动切分(split)到多个节点 2.当集群中的某一个节点故障时,redis还可以继续处理客户端的请求. 一个 redis 集群包含 16384 个哈希槽(hash slot),数据库中的每个数据都属于这16384个哈希槽中的一个.集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽.集群中

  • Redis集群下过期key监听的实现代码

    1. 前言 在使用redis集群时,发现过期key始终监听不到.网上也没有现成的解决方案.于是想,既然不能监听集群,那我可以建立多个redis连接,分别对每个redis的key过期进行监听.以上做法可能不尽人意,目前也没找到好的解决方案,如果有好的想法,请留言告知哦!不多说,直接贴我自己的代码! 2. 代码实现 关于Redis集群配置代码此处不贴,直接贴配置监听类代码! redis.host1: 10.113.56.68 redis.port1: 7030 redis.host2: 10.113

  • Redis集群与SSM整合使用方法

    首先是创建redis-cluster文件夹: 因为redis最少需要6个节点(三主三从),为了更好的理解,我这里创建了两台虚拟机(192.168.0.109 192.168.0.110),分别在两台虚拟机的/opt/redis-4.0.1/redis-cluster下创建三个节点文件夹 192.168.0.109: 192.168.0.110: 以上6个节点全部创建完成,分别再在这六个文件夹下创建redis.conf配置文件,其中配置如图: port 7000 bind 192.168.0.10

  • 详解redis集群选举机制

    概要 当redis集群的主节点故障时,Sentinel集群将从剩余的从节点中选举一个新的主节点,有以下步骤: 故障节点主观下线 故障节点客观下线 Sentinel集群选举Leader Sentinel Leader决定新主节点 选举过程 1.主观下线 Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常.如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包,则该redis节点被该Sentinel

  • 详解Redis集群搭建的三种方式

    一.单节点实例 单节点实例还是比较简单的,平时做个测试,写个小程序如果需要用到缓存的话,启动一个 Redis 还是很轻松的,做为一个 key/value 数据库也是可以胜任的 二.主从模式(master/slaver) redis 主从模式配置 主从模式: redis 的主从模式,使用异步复制,slave 节点异步从 master 节点复制数据,master 节点提供读写服务,slave 节点只提供读服务(这个是默认配置,可以通过修改配置文件 slave-read-only 控制).master

  • 详解redis集群的三种方式

    目录 主从复制 基本原理 持久化开关 配置 哨兵模式 基本原理 启动 配置 故障迁移 Cluster集群 键分布模型 配置cluster集群 启动集群 Redis三种集群方式:主从复制,哨兵模式,Cluster集群. 主从复制 基本原理 当新建立一个从服务器时,从服务器将向主服务器发送SYNC命令,接收到SYNC命令后的主服务器会进行一次BGSAVE命令,在执行期间,会将所有命令写入缓冲区中,当BGSAVE命令执行完毕之后会将生成的RDB文件发送给从服务器,从服务器使用这个文件加载数据到内存中,

  • 详解mysql集群:一主多从架构实现

    实验环境: 1.三台CentOS 7 服务器 2.mysql5.7.26(三台都通过yum安装) 服务器列表 7.100.222.111 master 47.103.211.5 slave1 47.103.98.221 slave2 如果还没安装mysql请看安装教程:mysql安装 一.概述: 架构图: 此种架构,一般初创企业比较常用,也便于后面步步的扩展 特点: 1.可以缓解读的压力. 2.成本低,布署快速.方便 3.读写分离 4.还能通过及时增加从库来减少读库压力 5.主库单点故障 6.数

  • 详解Tomcat集群如何同步会话

    Tocmat集群中最重要的交换信息就是会话消息,对某个tomcat实例某会话做的更改要同步到集群其他tomcat实例的该会话对象,这样才能保证集群所有实例的会话数据一致.在tribes组件的基础上完成这些工作就相当容易些,tribes是tomcat实现的一个通信框架. 如下图,tomcat实现会话同步的过程中大致会使用如下组件,现在假设中间的tomcat实例的会话改变了,它会通过会话管理器Manager将改变的动作消息封装成消息然后调用集群对象Cluster,通过Cluster将消息发送出去,同

  • 详解MySQL集群搭建

    概述 MySQL Cluster 是MySQL 适合于分布式计算环境的高实用.可拓展.高性能.高冗余版本,其研发设计的初衷就是要满足许多行业里的最严酷应用要求,这些应用中经常要求数据库运行的可靠性要达到99.999%.MySQL Cluster允许在无共享的系统中部署"内存中"数据库集群,通过无共享体系结构,系统能够使用廉价的硬件,而且对软硬件无特殊要求.此外,由于每个组件有自己的内存和磁盘,不存在单点故障. 实际上,MySQL集群是把一个叫做NDB的内存集群存储引擎集成与标准的MyS

  • 比较几种Redis集群方案

    目录 一.概述 二.Redis高可用集群搭建 三.Redis集群节点间的通信机制 3.1.集中式 3.2.gossip 四.网络抖动 五.Redis集群选举原理分析 5.1.集群是否完整才能对外提供服务 5.2.Redis集群为什么至少需要三个master节点,并且推荐节点数为奇数? 5.3.哨兵leader选举流程 六.新增/删除节点 一.概述 在Redis3.0以前的集群一般是借助哨兵sentinel工具来监控主节点的状态,如果主节点异常,则会做主从切换,将某一台slave作为master.

  • redis集群规范详解

    本文档翻译自 http://redis.io/topics/cluster-spec . 引言 这个文档是正在开发中的 Redis 集群功能的规范(specification)文档, 文档分为两个部分: 第一部分介绍目前已经在 unstable 分支中实现了的那些功能. 第二部分介绍目前仍未实现的那些功能. 文档各个部分的内容可能会随着集群功能的设计修改而发生改变, 其中, 未实现功能发生修改的几率比已实现功能发生修改的几率要高. 这个规范包含了编写客户端库(client library)所需的

  • Redis集群详解

    Redis集群详解 Redis有三种集群模式,分别是: * 主从模式 * Sentinel模式 * Cluster模式 三种集群模式各有特点,关于Redis介绍可以参考这里:NoSQL(二)--Redis Redis官网:https://redis.io/ ,最新版本6.0.5 主从模式 主从模式介绍 主从模式是三种模式中最简单的,在主从复制中,数据库分为两类:主数据库(master)和从数据库(slave). 其中主从复制有如下特点: * 主数据库可以进行读写操作,当读写操作导致数据变化时会自

  • Redis集群的相关详解

    注意!要求使用的都是redis3.0以上的版本,因为3.0以上增加了redis集群的功能. 1.redis介绍 1.1什么是redis Redis是用C语言开发的一个开源的高性能键值对(key-value)的非关系型数据库.通过多种键值数据类型来适应不同场景下的存储需求,目前支持的键值数据类型有: 字符串,散列,列表,集合,有序集合 2.2应用场景 缓存(数据查询.短连接.新闻内容.商品内容等等).(最多使用) 分布式集群架构中的session分离. 聊天室的在线好友列表. 任务队列.(秒杀.抢

随机推荐

其他