Redis | 哨兵模式-选举策略

最新推荐文章于 2025-04-24 11:51:46 发布
最新推荐文章于 2025-04-24 11:51:46 发布
阅读量1.2k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： Redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/ThinPikachu/article/details/121590503
本文详细介绍了Redis哨兵(Sentinel)系统中检测主观下线、检查客观下线状态、选举领头Sentinel的过程，以及故障转移的三个步骤：选择新主服务器、修改从服务器复制目标和将旧主服务器设为从服务器。通过哨兵的机制，确保集群高可用性和数据一致性。

目录

一、检测主观下线

二、检查客观下线状态

 三、选举领头 Sentinel

四、故障转移

（1）选出新的主服务器

（2）修改从服务器的复制目标

（3）将旧的主服务器变为从服务器

一、检测主观下线

        在默认情况下， Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他 Sentinel在内）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

        在下图展示的例子中，带箭头的连线显示了 Sentinel1和 Sentinel2是如何向实例发送PING命令的：

Sentinel1将向 Sentinel2、主服务器 master、从服务器 slave1和 slave2发送PING命令。
Sentinel2将向 Sentinel1、主服务器 master从服务器 slave1和save2发送PING命令。 

实例对PNG命令的回复可以分为以下两种情况：

  • 有效回复：实例返回-PONG、- LOADING、-MASTERDOWN三种回复的其中一种。
  • 无效回复：实例返回除-PONG、- LOADING、-MASTERDOWN三种回复之外的其他回复或者在指定时限内没有返回任何回复。

       

了解本专栏 订阅专栏 解锁全文 超级会员免费看
Redis 哨兵模式的选举算法是什么？
yonggeit的博客
09-15 760
总之，Redis 哨兵模式通过多个 Sentinel 节点的协作，实现了对主节点的自动监控、故障检测和故障转移，提高了 Redis 集群的可用性和可靠性。Sentinel 节点更新配置。
【Zookeeper】实现哨兵机制（选举策略）
diaolin2115的博客
09-16 539
一、Master选举使用场景及结构 二、代码实现 2.1 Maven依赖信息 2.2 IndexController 2.3 MyApplicationRunner 2.4 ElectionMaster 一、Master选举使用场景及结构 现在很多时候我们的服务需要7*24小时工作，假如一台机器挂了，我们希望能有其它机器顶替它继续工作。此类问题现在...
Redis哨兵模式中的选举算法：Raft vs Paxos
TaloyerG的博客
12-12 4058
哨兵模式是在主从模式的基础上，引入了哨兵（sentinel）节点，用于监控主节点和从节点的运行状态，并在主节点发生故障时，自动将一个从节点升级为新的主节点，实现主节点的自动故障转移。哨兵模式可以提高Redis的可用性和容错性，是实现Redis高可用的一种常用方式。自动故障转移，无需人工干预，减少了服务中断和数据丢失的风险集群监控，可以实时感知主从节点的健康状况，及时发现和处理异常情况配置中心，可以提供主节点的动态发现和通知服务，方便客户端的连接和切换。
Redis 5 集群选举原理分析
挂机的阿洋zzZ
12-16 9279
Redis集群选举原理 开始之前，先说下这个参数 cluster-node-timeout 真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。 为解决这种问题，Redis Cluster 提供了一种选项cluster-node-timeout，表示当某个节点持续 timeout 的时间...
redis集群选举机制
热门推荐
祈雨v的博客
02-02 2万+
概要 当redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤： 故障节点主观下线 故障节点客观下线 Sentinel集群选举Leader Sentinel Leader决定新主节点 选举过程 1、主观下线 Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-m...
redis哨兵模式选举机制
LiaoHongHB的博客
10-15 1万+
当redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤： 故障节点主观下线故障节点客观下线Sentinel集群选举LeaderSentinel Leader决定新主节点 选举过程 1、主观下线 Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该redis节点被该Sentinel节点主观下线。
十三、Redis哨兵模式--Sentinel
qq_41056506的博客
05-12 963
每个Sentinel以每秒一次的频率向他所知master、slave以及其他Sentinel发送一次ping命令。如果一个实例距离最后一次回复ping命令的时间超过指定的值，则这个实例会被Sentinel标记为主观下线。如果一个master被标记为主观下线，则正在监控这个master的其他Sentinel要以每秒一次的频率确认master是否进入主观下线。如果有足够数量的Sentinel(大于等于quorum指定的值)认为master确实处于主观下线状态，那么master会被标记为客观下线。
搭建Redis集群&哨兵模式- Linux环境
zmm19880310的博客
03-25 941
说明：每个redis都可以部署在同一服务器上。主要是为了保证redis的高可用性，当一个redis坏掉了，还有其他的redis可提供服务，所以需要搭建redis集群。在这里分为三大部分：linux上安装redis搭建redis集群(主从集群)搭建redis哨兵模式在linux上安装redis1.1下载redis地下：https://download.redis.io/releases/另一个下载方式，当前服务器是否允许访问外网，如果可以的话，
实战——使用dokcer配置Redis的哨兵模式
qq_51321722的博客
10-14 701
从上面截图中可以看出，领头sentinel重新选出了一个master节点，127.0.0.1:6380，然后发送命令给其他的从服务节点，让他们成为新主服务节点的从服务节点，这就是哨兵模式高可用的原因之一，当redis-master挂掉以后，sentinel会选出一个领头sentinel，这个领头sentinel又会继续从从服务器列表中选出一个master节点，再通知其余的从节点成为这个主节点的从节点，这就完成了主节点切换的工作。由于这段内容涉及的ip地址太多，所以很多地方给模糊处理了一下，请谅解~
redis在集群模式下主节点的选举
weixin_42279822的博客
11-07 1340
无论采用哪种策略，主节点的选举是确保Redis集群高可用性的关键环节，应当得到特别关注和合适的配置。这些机制使用不同的选举策略来确保新的主节点的选举是可靠和高效的。这可以确保新的主节点具有更多的数据一致性，但也要求有足够多的节点参与选举。：当一个主节点被标记为失效时，Redis集群会从已有的从节点中选举一个新的主节点。：在Redis集群中，节点可以担任主节点或从节点的角色。这些协议确保在失效主节点的情况下，只有一个新的主节点被选举。：选举策略通常包括检测主节点的故障，以及检查潜在的主节点的健康状况。
理解主从策略，哨兵模式
IAMZTDSF的博客
03-18 2054
平时用主数据库去扛，一旦崩溃了就用从数据库来代替 两哨兵也是一个崩溃了另一个扛，哨兵用来决定哪个是主数据库 主采用分库策略 单台数据库承受并发量有限，分库策略，把不同的表分别放入不同的库，多库多主多从。 哨兵机制 搭建哨兵并不需要写代码，改一下配置文件就行（普通启动，哨兵启动） 读写时数据库分别有两种策略（集群（读）和分布式（写）） 多主提升数据库抗压能力 缓存适合缓存访问频率高，不常更改的数据 如果访问频率高，又经常被修改就不适合做缓存就使用分库策略，一个库连这个表，一个库连那个表
Redis集群选举策略
最新发布
qq_61504864的博客
04-24 677
当 Redis 集群中的主节点出现故障，无法正常响应心跳包时，从节点会感知到主节点的故障，进而触发选举流程，选举出新的主节点来替代故障的主节点。
Redis(二)持久化和集群选举机制
weixin_43442659的博客
03-10 754
持久化，主从，哨兵架构，内存淘汰机制 这次来介绍redis持久化，主从，哨兵架构。对于持久化而言，除非是那种数据无关紧要，数据量少，说明是当纯内存在做缓存。其他情况下一般是开启持久化，因为如果不开启持久化，当redis宕机时，缓存被击穿，大量请求落到mysql上，mysql会撑不住的，redis的持久化方式分为三种，包括rdb，aof和混合模式。 RDB 所谓的rdb就是一个快照机制，是对redis中的数据执行周期性的持久化。可以在conf文件下设置多少秒内改动多少次数据会触发rdb快照机制，他会将内存中的
Zookeeper实现Master选举（哨兵机制）
weixin_30784141的博客
11-04 129
master选举使用场景及结构 　现在很多时候我们的服务需要7*24小时工作，假如一台机器挂了，我们希望能有其它机器顶替它继续工作。此类问题现在多采用master-salve模式，也就是常说的主从模式，正常情况下主机提供服务，备机负责监听主机状态，当主机异常时，可以自动切换到备机继续提供服务(这里有点儿类似于数据库主库跟备库，备机正常情况下只监听，不工作)，这个切换过程中选出下一个主机的过程就是...
6.哨兵模式自动选取
weixin_47039303的博客
05-24 295
1.哨兵模式(自动选老大)(投票的方式)(哨兵,会相互通知其他哨兵,有没有挂了) (通知主节点下面从机的状态,也可以通知从机主机的状态) //配置哨兵 vim sentinel //里面写 名字,...., 主机名称 ... 选举谁 sentinel monitor myredis 127.0.0.1 6379 1 //启动哨兵 redis-sentinel sentinel.conf //failover故障转移 //主机回来了,只能当从机
Redis篇——一篇文章带你彻底拿下Sentinel哨兵模式(自动选举老大的模式)技术点，超详细、保姆级别教程奉上，不要错过~
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
12-08 3482
一、概述和实现逻辑主从切换技术的方法是，当主服务器宕机后，需要手动把一台从服务器通过命令切换为主服务器，这就需要人工干预，还会造成一段时间内服务不可用。这不是一种值得推荐的方式，更多的时候，我们会优先考虑哨兵模式！！！哨兵模式，是一个分布式系统：通俗的讲，就是一种谋朝篡位的自动版，能够在后台监控主机是否故障，如果故障了，会根据投票自动将从服务器转换为主服务器。用于监控和管理Redis实例的高可用性。在Redis Sentinel中，哨兵实例之间通过PING和PONG消息进行通信。
Redis集群选举流程详解
EverythingAtOnce的博客
01-22 2920
Redis集群选举是确保系统高可用性的关键步骤，通过哨兵节点的通信、投票和算法，集群能够迅速适应主节点的变化。了解选举流程并结合实际应用，有助于保障系统的稳定性和可用性。希望本文提供的详细解释和Java代码示例对大家理解Redis集群选举流程有所帮助。Redis持久化、主从与哨兵架构详解-优快云博客Redis为何如此快速？-优快云博客如何在Linux上使用Java命令排查CPU和内存问题_visualvm217-优快云博客JVM性能调优-垃圾收集器ParNew-优快云博客。
redis 哨兵模式
weixin_68256171的博客
08-19 1368
哨兵也叫 sentinel，它的作用是能够在后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
Redis（21）—— 哨兵模式
weixin_45418001的博客
06-01 617
哨兵模式 （自动选举老大的模式） 概述 主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工 干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。 谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独 立运行。其原
redis对比哨兵模式和集群模式
03-27
<think>好的，我现在需要回答用户关于Redis哨兵模式和集群模式对比的问题。用户可能正在设计一个分布式系统，需要选择合适的Redis高可用方案。他们可能已经了解了一些基本概念，但想深入理解两者的区别、适用场景以及优缺点。 首先，我应该回顾哨兵模式（Sentinel）和集群模式（Cluster）的基本功能。哨兵模式主要用于监控主从节点，实现故障转移，确保高可用。而集群模式不仅提供高可用，还通过分片（Sharding）实现数据的水平扩展，提升性能和容量。 接下来，需要比较两者的关键点。比如数据分布方式、高可用机制、扩展性、客户端支持等。要确保信息准确，可能需要查阅官方文档或可靠资料。比如，哨兵模式每个主节点有多个从节点，数据是完整的副本；而集群模式将数据分片到多个主节点，每个分片有从节点备份。 还要注意用户可能的误区，比如是否集群模式一定比哨兵好，或者两者是否可以结合使用。需要指出各自的适用场景，例如哨兵适合读多写少、数据量不大的情况，而集群适合数据量大、需要高吞吐的场景。 另外，用户可能关心配置复杂度。哨兵模式配置相对简单，而集群需要更多的节点和分片管理，运维复杂度高。同时，客户端支持方面，集群模式需要客户端兼容，可能需要更新或使用特定驱动。 最后，总结两者的优缺点，帮助用户根据具体需求选择。比如，如果数据量小但需要高可用，哨兵可能更合适；如果需要扩展性和大容量，集群更优。同时提醒潜在问题，如网络分区处理、性能影响等。</think>--- ### Redis 哨兵模式 vs 集群模式：核心差异与适用场景 Redis 的 **哨兵模式（Sentinel）** 和 **集群模式（Cluster）** 均用于实现高可用和容灾，但设计目标、数据分布方式和适用场景有本质区别。以下从 **6个核心维度** 对比两者的差异： --- #### **1. 核心目标** | **模式** | **核心目标** | **适用场景** | | --- | --- | --- | | **哨兵模式** | 解决 **主从架构的高可用性**（故障自动切换） | 数据量较小，读写压力低，需保证服务持续可用 | | **集群模式** | 实现 **数据分片（Sharding）+ 高可用**（横向扩展与容灾） | 数据量大、高并发、需突破单机性能瓶颈 | --- #### **2. 数据分布方式** | **模式** | **数据分布** | **特点** | | --- | --- | --- | | **哨兵模式** | **主从全量复制**：主节点存储完整数据，从节点为完整副本 | 数据冗余度高，但单节点容量受限于内存 | | **集群模式** | **分片存储**：数据按哈希槽（16384 slots）分配到不同主节点 | 支持水平扩展，单节点只需存储部分数据 | --- #### **3. 高可用机制** | **模式** | **故障转移** | **容灾粒度** | | --- | --- | --- | | **哨兵模式** | 哨兵节点监控主从状态，主节点故障时选举新主 | 以主节点为单位切换（单点故障影响整个主节点数据） | | **集群模式** | 每个分片有主从结构，主节点故障时从节点接管 | 以分片为单位切换（仅故障分片受影响，其他分片正常服务） | --- #### **4. 扩展性对比** | **模式** | **读写扩展** | **容量扩展** | | --- | --- | --- | | **哨兵模式** | 读请求可通过从节点扩展，**写性能受限于主节点** | 无法突破单机内存限制 | | **集群模式** | 读写均分散到不同分片，**性能随分片数量线性增长** | 容量随分片数量扩展，支持 PB 级数据 | --- #### **5. 客户端兼容性** | **模式** | **客户端要求** | **透明性** | | --- | --- | --- | | **哨兵模式** | 客户端需支持 Sentinel 协议，自动发现主节点地址 | 对业务代码侵入较小 | | **集群模式** | 客户端需支持 Cluster 协议，理解哈希槽分布（如重定向机制） | 需使用集群兼容的客户端库（如 JedisCluster） | --- #### **6. 运维复杂度** | **模式** | **部署复杂度** | **运维风险** | | --- | --- | --- | | **哨兵模式** | 部署简单，仅需配置 Sentinel 节点和主从结构 | 网络分区可能导致脑裂（需合理配置 `quorum`） | | **集群模式** | 需规划分片数量、节点分布，部署复杂度高 | 分片迁移、扩容需谨慎操作（如 `reshard` 命令） | --- #### **选型建议** - **选择哨兵模式**： ✅ 数据量小（单机内存可容纳） ✅ 读多写少，且读压力可通过从节点分担 ✅ 希望快速实现高可用，降低运维成本 - **选择集群模式**： ✅ 数据量超单机内存（需分片存储） ✅ 高并发读写（如 QPS 超过 10万） ✅ 需要线性扩展能力（未来可能持续增长） --- #### **典型问题与注意事项** 1. **哨兵模式的瓶颈**： - 主节点故障后，切换期间写入会短暂阻塞（默认配置约 10-30 秒）。 - 单主节点写性能上限约为 10万 QPS（依赖硬件）。 2. **集群模式的限制**： - 不支持跨分片事务（如 `MULTI` 操作需所有 key 在同一分片）。 - 分片迁移时可能影响性能（需避免高峰操作）。 3. **混合部署方案**： - 可将集群模式的分片主节点配置为哨兵模式（进一步提升分片的高可用性）。 --- #### **性能对比示例** | **场景** | **哨兵模式（1主2从）** | **集群模式（3主3从）** | | --- | --- | --- | | 数据容量 | 单机内存上限（如 64GB） | 3倍单机内存（如 192GB） | | 理论写 QPS | ~10万（主节点瓶颈） | ~30万（3个主节点并行） | | 故障恢复时间 | 10-30秒（依赖哨兵选举） | 1-3秒（分片级快速切换） | --- **总结**：哨兵模式是轻量级高可用方案，集群模式是分布式扩展方案，两者并非互斥，可根据业务需求组合使用（如集群分片内部部署哨兵）。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值