Redis哨兵模式

最新推荐文章于 2025-10-14 19:11:33 发布
原创 最新推荐文章于 2025-10-14 19:11:33 发布 · 512 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了Redis的主从复制机制，包括读写分离和容灾恢复，并详细阐述了如何搭建主从复制环境。接着讨论了主从复制中可能出现的问题，如一仆二主和薪火相传的情况。重点介绍了哨兵模式，它能自动实现故障转移，当主服务器宕机时，哨兵会选择新的主服务器，确保系统的高可用性。文中还展示了哨兵模式的配置和测试过程。

1：主从复制

要知道哨兵模式之前需要知道什么是Redis的主从复制：主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
1. 读写分离，性能扩展
2. 容灾快速恢复

2：Redis搭建主从复制

需要几个Redis服务器就创建几个配置文件：配置文件格式为redis+端口号.conf
配置文件内容：

include (redis.conf文件位置)
pidfile (/var/run/redis_Redis服务端口号.pid)
port (Redis服务端口号)
dbfilename (生成的rdb文件名)

比如Redis主服务器的端口号为6379则配置如下：

include redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

配置好主服务器和从服务器后运行Redis即可：
主服务负责写操作，而从服务器只能读取不能写，在主服务器写的数据可以在从服务器读取到。

3：主从复制的问题

3.1：一仆二主

1：当从服务器宕机期间，主服务器继续进行写操作，当从服务器重启后，会变成主服务器，需要重新slaveof配置成为从服务器，且可以读取宕机期间期间主服务器添加的数据。
2：当主服务器宕机，从服务器不会充当主服务器，当主服务器重启后还是主服务器。

3.2：薪火相传

上一个从服务器可以是下一个从服务器的主服务器，从服务器同样可以接收其他从服务器的连接和同步请求，那么该从服务器作为了链条中下一个的主服务器， 可以有效减轻主服务器的写压力,去中心化降低风险。

  1. 中途变更转向:会清除之前的数据，重新建立拷贝最新的
  2. 风险是一旦某个从服务器宕机，后面的从服务器都没法备份
  3. 主机挂了，从机还是从机，无法写数据了

3.3：反客为主

当一个主服务器宕机后，后面的从服务器可以立刻升为主服务器，其后面的从服务器不用做任何修改。

用 slaveof no one 命令 将从机变为主机。

4：哨兵模式-自动反客为主

反客为主需要我们手动执行命令slaveof no one进行从机到主机的变换，很不方便，所以引入哨兵模式，当主服务器宕机后，哨兵会从剩下的从服务器选择一个作为新的主服务器，而宕机的主服务器重启后作为新的从服务器。

实现哨兵模式：比如现在主服务器为redis6379，从服务器为redis6380和redis6381。

1：新建 sentinel.conf 文件，名字绝不能错
配置内容为sentinel monitor mymaster Redis服务器IP 6379 1
添加这段话：其中mymaster为监控对象起的服务器名称， 1 的意思是：至少有多少个哨兵同意迁移的数量。

2：启动哨兵进程

[root@LKCentos01 bin]# redis-sentinel sentinel.conf 
14067:X 23 Apr 2022 10:30:48.243 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14067:X 23 Apr 2022 10:30:48.243 # Redis version=6.2.1, bits=64, commit=00000000, modified=0, pid=14067, just started
14067:X 23 Apr 2022 10:30:48.243 # Configuration loaded
14067:X 23 Apr 2022 10:30:48.244 * Increased maximum number of open files to 10032 (it was originally set to 1024).
14067:X 23 Apr 2022 10:30:48.244 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.1 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379  哨兵端口
 |    `-._   `._    /     _.-'    |     PID: 14067   哨兵进程ID
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

14067:X 23 Apr 2022 10:30:48.244 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
14067:X 23 Apr 2022 10:30:48.245 # Sentinel ID is 5488eb452f9b968168ef397b4d978227d271170d
14067:X 23 Apr 2022 10:30:48.245 # +monitor master mymaster RedisIP 6379 quorum 1   #监视主服务器redis6379

3：测试哨兵

#6379主机宕机
Redis服务器IP:6379> SHUTDOWN
not connected> quit

#查看6380、6381的信息
#6380作为从机
Redis服务器IP:6380> info replication
# Replication
role:slave
master_host:Redis服务器IP
master_port:6381
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:50433
slave_priority:100
slave_read_only:1
connected_slaves:0
master_failover_state:no-failover
master_replid:d6e90344a4f9f115eeb3c3bf9a646a1cfcbde14a
master_replid2:982754621d55bcbd27b20d46136aea3e86ec6531
master_repl_offset:50433
second_repl_offset:30023
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:50433

#6381作为新的主机
Redis服务器IP:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=Redis服务器IP,port=6380,state=online,offset=52505,lag=0
master_failover_state:no-failover
master_replid:d6e90344a4f9f115eeb3c3bf9a646a1cfcbde14a
master_replid2:982754621d55bcbd27b20d46136aea3e86ec6531
master_repl_offset:52505
second_repl_offset:30023
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:52463

4：重启宕机的主服务器

重启后作为新主服务器的从服务器

[root@LKCentos01 myRedis]# clear
[root@LKCentos01 myRedis]# redis-server redis6379.conf 
[root@LKCentos01 myRedis]# redis-cli 
Redis服务器IP> info replication
# Replication
role:slave
master_host:Redis服务器IP
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:126158
slave_priority:100
slave_read_only:1
connected_slaves:0
master_failover_state:no-failover
master_replid:d6e90344a4f9f115eeb3c3bf9a646a1cfcbde14a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:126158
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:126159
repl_backlog_histlen:0

5：哨兵选取新主服务器原则

  1. 优先级在redis.conf中默认：slave-priority 100(版本不同可能为-replica-priority 100)，值越小优先级越高。
  2. 偏移量是指获得原主机数据最全的(即复制原主服务器内容最全的从服务器)。
  3. 每个redis实例启动后都会随机生成一个40位的runid，选最小的。
Redis——Redis 哨兵模式
Cantevenl的博客
04-19 3万+
Redis 哨兵模式哨兵模式的简介哨兵的作用启用哨兵模式配置哨兵启动哨兵哨兵模式的工作原理阶段一：监控阶段阶段二：通知阶段阶段三：故障转移阶段发现故障选出领头sentinel挑选备选master主从切换总结 哨兵模式的简介 主从切换技术的方法是︰当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵）架构来解决这个问题。 哨兵(se
redis哨兵模式
踏 浪的博客
11-09 565
目录 1、创建哨兵配置文件 （sentinel.conf） 2、启动redis主从模式 3、启动哨兵模式 4、测试 5、补充 本章紧接着的是上一章 redis 主从复制 ：https://blog.youkuaiyun.com/u010559460/article/details/109238874 redis主从复制：仅仅解决的是我们redis数据冗余备份，从节点只是用来备份数据。无法解决 当master 节点出现故障的时候实现自动故障转移 本章将介绍使用 redis哨兵模式 解决当master解决.
Redis 哨兵模式
最新发布
蓝鲸鱼计算机软件开发工作室
10-14 783
摘要： Redis 哨兵模式是一种高可用性解决方案，用于在分布式环境中管理主从复制。它通过选举机制确保只有一个节点担任主节点的角色，从而避免了单点故障。哨兵模式支持多种数据同步策略，包括基于时间戳的快照和基于哈希的复制。此外，它还提供了一些监控和管理功能，如健康检查和日志记录，以帮助管理员维护系统的稳定运行。
Redis 主从 + 哨兵集群部署
2501_91350469的博客
06-06 3240
在一主多从的 Redis 架构中，从节点可以起到数据冗余备份和读写分离的作用。如果主节点遇到故障导致无法提供服务时，可以采用手动方式将其一个从节点提升为主节点，保证 Redis 主从能够正常工作。主从切换通过手动完成比较耗时、费力，并且影响 Redis 正常服务。为此，Reids 提供了哨兵功能，实现了自动化的系统监控和故障恢复功能。哨兵(Sentine1)，主要负责监控主从节点运行是否正常，以及当主节点出现故障时自动将一个从节点转换为新的主节点。哨兵是一个独立的进程。
精选资源
Redis哨兵模式配置文件
03-26
在Windows环境下配置Redis哨兵模式，你需要按照以下步骤操作： 1. 安装Redis服务：首先需要在每台服务器上安装Redis服务，并配置相应的redis.conf文件。 2. 配置哨兵：然后，为每个哨兵节点创建并编辑sentinel.conf...
基于hiredis封装的redis哨兵模式的C++库（跨平台支持）
05-11
这个是我自己用C++写的基于hiredis封装的redis哨兵模式的库，支持windows/linux 跨平台编译, windows下是静态库，linux编译出来是动态库so 该库功能包含了redis哨兵模式的服务启动，关闭，几乎涵盖了所有常用的...
精选资源
docker-compose构建Redis哨兵模式镜像包
01-09
docker-compose构建Redis哨兵模式镜像包
集群redis哨兵模式连接方式，解决database不生效问题（附源码）
05-20
本文将详细介绍如何在集群环境中设置Redis哨兵模式，并解决在该模式下database配置不生效的问题，同时提供相关的源码示例。 首先，理解Redis哨兵模式的核心概念。哨兵系统是一个监控和故障转移机制，它可以监控多个...
Redis—哨兵模式
weixin_71964451的博客
07-03 2386
上述过程, 都是 “⽆⼈值守” , Redis ⾃动完成的。这样做就解决了主节点宕机之后需要人工干预的问题,提高了系统的稳定性和可用性。哨兵节点不能只有⼀个。否则哨兵节点挂了也会影响系统可⽤性.哨兵节点最好是奇数个。方便选举 leader, 得票更容易超过半数.哨兵节点不负责存储数据。仍然是 redis 主从节点负责存储.哨兵 + 主从复制解决的问题是 “提⾼可⽤性”, 不能解决 “数据极端情况下写丢失” 的问题.
redis的哨兵模式
My_daidai的博客
07-09 304
上篇我们讲了主从同步。有一个问题无法解决，细想如果主节点宕机了，从节点升为主节点，这需要手工进行主从切换，程序也需要手动去修改节点地址。如果是大半夜发生，这就是一场严重的事故了。 针对这种场景咱们的Redis提供了一套高可用的方案，Redis sentinel。 Redis 的 Sentinel 可以用来管理多个 Redis 服务器，会执行以下四个任务： 1.监控 Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。 2.通知 当被监控的某个 Redis 服务器出现问题，Sentinel
Redis的哨兵模式
热门推荐
qq_44299529的博客
03-03 3万+
引子 Master挂了，如何保证可用性，实现继续读写 什么是哨兵 Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是Redis高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务。 某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。 （顺带提一句，即使后来之前的master重启服务，也不会变回master了，而是作为slave从服务） 哨兵模式原理图
redis 哨兵模式
06-13
<think>我们正在讨论Redis哨兵模式的配置与实现。根据引用内容，用户提供了几个配置示例，但我们需要系统地解释哨兵模式的配置步骤和实现原理。步骤1：理解哨兵模式Redis哨兵（Sentinel）是一个分布式系统，用于管理多个Redis实例（主从结构），提供自动故障转移（failover）和高可用性。哨兵模式的核心功能包括：-监控：哨兵定期检查主节点和从节点的状态。-通知：当被监控的实例出现问题时，哨兵可以通过API通知系统管理员或其他程序。-自动故障转移：如果主节点故障，哨兵会启动故障转移过程：选择一个从节点晋升为主节点，并让其他从节点复制新的主节点。-配置提供者：客户端可以通过哨兵获取当前主节点的地址。步骤2：配置哨兵模式的基本步骤根据引用[2]和引用[3]，配置哨兵模式通常包括以下步骤：1.准备Redis主从结构：首先需要配置一个主节点和至少一个从节点。例如：-主节点：运行在127.0.0.1:6380-从节点1：运行在127.0.0.1:6381-从节点2：运行在127.0.0.1:63822.创建哨兵配置文件：每个哨兵实例需要一个配置文件。通常，我们会创建多个哨兵实例（通常为奇数，如3个）以实现哨兵自身的容错。以配置三个哨兵为例（端口分别为26380,26381,26382）：-复制模板配置文件：创建三个哨兵配置文件（如sentinel-26380.conf,sentinel-26381.conf,sentinel-26382.conf）。-修改每个配置文件，主要设置：port<哨兵端口>#每个哨兵使用不同端口daemonizeyes#以守护进程方式运行sentinelmonitor<master-group-name><master-ip><master-port><quorum>sentinelauth-pass<master-group-name><password>#如果主节点有密码例如：sentinelmonitormymaster127.0.0.163802sentinelauth-passmymaster123456注意：`<quorum>`（法定人数）是判定主节点故障至少需要的哨兵数量。这里设置为2，表示需要至少两个哨兵同意才能判定主节点故障。3.启动哨兵：redis-sentinel/path/to/sentinel-26380.confredis-sentinel/path/to/sentinel-26381.confredis-sentinel/path/to/sentinel-26382.conf4.验证：连接到一个哨兵实例，使用`infoSentinel`命令查看状态。步骤3：哨兵模式的工作原理-哨兵通过发送PING命令定期检查主从节点的健康状态。-如果主节点在配置的`down-after-milliseconds`时间内未回复，哨兵将其标记为“主观下线”。-当足够数量的哨兵（达到quorum）都将主节点标记为主观下线时，主节点被标记为“客观下线”。-然后，哨兵会选举一个领导者哨兵（使用Raft算法）来执行故障转移。-领导者哨兵选择一个从节点（通常选择数据最新的从节点）晋升为主节点，并让其他从节点复制新的主节点。-最后，哨兵更新配置：将旧主节点（如果重新上线）设置为新主节点的从节点。步骤4：注意事项-哨兵数量：通常至少需要3个哨兵以确保系统在部分故障时仍能正常工作（容忍一个哨兵故障）。-网络分区：哨兵系统需要大多数哨兵可达才能做出决策，因此奇数个哨兵（如3或5）可以避免脑裂。-客户端：客户端需要支持哨兵，能够通过查询哨兵获取当前主节点地址。步骤5：配置示例参考引用[2]中的配置片段，一个哨兵配置文件（如sentinel-26382.conf）可能如下：```plaintextport16382daemonizeyessentinelmonitormymaster127.0.0.163802sentinelauth-passmymaster123456```步骤6：启动和停止引用[3]展示了如何停止和启动所有节点（包括主从和哨兵）的示例命令。注意：生产环境中应避免直接使用kill命令，应使用服务管理工具。总结：Redis哨兵模式提供了高可用性，配置过程包括设置主从复制、配置多个哨兵实例以及启动哨兵。哨兵通过监控和自动故障转移确保Redis服务在节点故障时继续运行。§§相关问题§§1.Redis哨兵模式与集群模式有什么区别？2.如何配置哨兵的故障转移通知？3.哨兵模式在故障转移过程中如何处理客户端连接？4.如何监控哨兵系统的状态？</think>### Redis哨兵模式配置与实现 Redis哨兵（Sentinel）是一种高可用解决方案，用于监控主从架构中的Redis实例，实现自动故障检测和故障转移。以下是关键配置步骤和实现原理： #### **一、核心配置步骤** 1. **创建哨兵配置文件** 复制模板并修改端口和监听对象（每个哨兵独立配置）： ```bash cp sentinel-26380.conf sentinel-26381.conf cp sentinel-26380.conf sentinel-26382.conf ``` 配置文件内容示例： ```plaintext port 16381 # 哨兵端口 daemonize yes # 后台运行 sentinel monitor mymaster 127.0.0.1 6380 2 # 监控主节点，2为法定同意数 sentinel auth-pass mymaster 123456 # 主节点密码 ``` [^2] 2. **启动哨兵进程** 分别启动三个哨兵节点： ```bash redis-sentinel sentinel-16380.conf redis-sentinel sentinel-16381.conf redis-sentinel sentinel-16382.conf ``` [^2] 3. **验证哨兵状态** 连接Redis执行命令查看哨兵信息： ```bash redis-cli -p 16381 info Sentinel # 输出主节点状态、从节点列表等 ``` 4. **故障转移流程** - 哨兵通过PING命令检测节点健康 - 主节点超时未响应 → 标记为**主观下线** - 多数哨兵确认 → 升级为**客观下线** - 选举领导者哨兵执行故障转移 - 选择数据最新的从节点晋升为新主节点 - 更新其他从节点复制目标 #### **二、关键参数解析** | 配置项 | 说明 | 示例 | |--------|------|------| | `sentinel monitor <name> <ip> <port> <quorum>` | 定义监控的主节点 | `sentinel monitor mymaster 127.0.0.1 6380 2` | | `sentinel down-after-milliseconds` | 判定节点失效的毫秒数 | 默认30,000ms | | `sentinel failover-timeout` | 故障转移超时时间 | 默认180,000ms | | `sentinel parallel-syncs` | 故障转移时同步新主的从节点数 | 默认1 | #### **三、实现原理** 1. **分布式监控** 多个哨兵节点组成集群，通过Gossip协议通信，避免单点故障。 2. **Raft共识算法** 故障转移时通过Raft选举领导者哨兵，需满足： $$ \text{同意票数} \geq \left\lfloor \frac{\text{哨兵总数}}{2} \right\rfloor + 1 $$ 3. **配置自动传播** 新主节点确认后，哨兵自动修改其他节点的`redis.conf`和`sentinel.conf`，更新主节点地址[^1]。 #### **四、注意事项** 1. **节点数量** 推荐部署**至少3个哨兵**（奇数个），法定人数(quorum)通常设为 $\frac{N}{2} + 1$（N为哨兵总数）。 2. **网络分区处理** 当网络分裂时，少数分区中的旧主节点会被置为只读模式，防止数据冲突。 3. **客户端集成** 客户端需支持哨兵协议，通过`SENTINEL get-master-addr-by-name`动态获取主节点地址。 > **故障转移演示**： > 当主节点(6380)宕机时，哨兵日志会显示： > ```plaintext > +sdown master mymaster 127.0.0.1 6380 # 检测到故障 > +vote-for-leader ... # 开始选举 > +failover-state-select-slave master mymaster # 选择新主 > +promote-slave slave 127.0.0.1:6381 ... # 提升从节点 > +switch-master mymaster 127.0.0.1 6380 127.0.0.1 6381 # 切换完成 > ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值