Redis 哨兵模式的一些思考

最新推荐文章于 2025-02-16 21:54:44 发布
最新推荐文章于 2025-02-16 21:54:44 发布
阅读量10w+ 收藏 3
点赞数
分类专栏： 高性能编程 Redis 哨兵模式 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/hu10131013/article/details/107658021
版权

为什么会出现哨兵模式

 Redis主从复制模式下，如果主节点出现故障将不能再继续提供服务，需要人为将从节点提升为主节点，同时还需要通知各个应用新的主节点的地址，这个在很多场景下是不能接受的，哨兵模式能很好的解决这个问题

  • Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态

  • 在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用（HA）

  • 其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。

 哨兵的作用

  • 监控(Monitoring): 哨兵(sentinel) 会不断地检查集群中的Master和Slave是否运作正常。

  • 提醒(Notification):当被监控的某节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

  • 自动故障迁移(Automatic failover)：当一个Master客观下线时，哨兵(sentinel) 会开始一次自动故障迁移操作。

    • 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；

    • 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

    • Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

哨兵进程的工作方式

  • 每个Sentinel进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel进程发送一个 ping 命令。
  • 如果一个实例（instance）距离最后一次有效回复 ping 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
  • 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
  • 当有足够数量的 Sentinel（个数可配置）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
  • 在一般情况下， 每个Sentinel进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 info命令。
  • 当Master主服务器被 Sentinel进程标记为客观下线（ODOWN）时，Sentinel进程向下线的 Master主服务器的所有 Slave从服务器发送 info命令的频率会从 10 秒一次改为每秒一次。
  • 若没有足够数量的 Sentinel进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel进程发送 ping命令返回有效回复，Master主服务器的主观下线状态就会被移除。

哨兵服务理想部署方案 

 

进程如下 

# 在单台机器上做的测试
root     31363     1  0 7月28 ?       00:01:51 /mnt/redis/bin/redis-server 0.0.0.0:6380
root     31375     1  0 7月28 ?       00:01:57 /mnt/redis/bin/redis-server 0.0.0.0:6381
root     31387     1  0 7月28 ?       00:01:55 /mnt/redis/bin/redis-server 0.0.0.0:6382
root     31552     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26380 [sentinel]
root     31557     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26381 [sentinel]
root     31563     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26382 [sentinel]

哨兵服务发现和健康检查流程及故障切换流程

 

哨兵的启动和配置

# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的
# sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0

# 后台运行
daemonize yes

# 默认yes，没指定密码或者指定IP的情况下，外网无法访问
protected-mode no

# 哨兵的端口，客户端通过这个端口来发现redis
port 26380

# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信
# sentinel announce-ip

# 临时文件夹
dir /tmp

# 日志
logfile "/mnt/redis/logs/sentinel-26380.log"

# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 192.168.16.40 6380 2

# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000

# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel failover-timeout mymaster 3000

# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1

什么是主观下线

  • 使用ping命令
  • 主观下线：单个哨兵自身认为redis实例已经不能提供服务
  • 监测机制：哨兵向redis发送ping请求，+PONG、-LOADING、-MASTERDOWN这三种情况视为正常，其他回复均视为无效
  •  对应配置项：sentinel down-after-milliseconds mymaster 1000

哨兵如何知道Redis主从信息

  •  使用 redis-cli -p 6380 info Replication命令去获取主从关系
  • 对应配置信息 
    
# Generated by CONFIG REWRITE
pidfile "/var/run/redis.pid"
user default on nopass ~* +@all
sentinel failover-timeout mymaster 3000
sentinel config-epoch mymaster 3
sentinel leader-epoch mymaster 3
sentinel known-replica mymaster 192.168.16.40 6381 #记录了从属节点6381
sentinel known-replica mymaster 192.168.16.40 6382 #记录了从属节点6382   
sentinel known-sentinel mymaster 192.168.16.40 26381 4cabf69629c1401289b6d3d239eba18b45da0041
sentinel known-sentinel mymaster 192.168.16.40 26382 20d8240e06a10cd887b752026c00de0318761eb8
sentinel current-epoch 3

     

什么是客观下线

  • 使用SENTINEL is-master-down-by-addr命令询问其他哨兵master节点是否已经下线
  • 客观下线：一定数量之的哨兵认为master已经下线，即可判定为master客观下线
  • 检测机制：当哨兵主观认为master下线后，会通过SENTINEL is-master-down-by-addr命令询问其他哨兵是否master已经下线，如果达成共识(达到quorum个数)，就认为master节点客观下线，开始故障转移流程
  • 对应的配置项：sentinel monitor mymaster 192.168.16.40 6380 2

哨兵之间如何通信(发布订阅机制)

  • slaveof 主从连接
  •  sentinel 向Master 发送 SUBSCRIBE 命令，订阅 Master 的 Hello Channel （SUBSCRIBE __sentinel__:hello），等待接收消息
  •  sentinel 向 Master 发送 INFO 命令，获取服务信息，及发现主从关系（获取到 Slave 信息）
  •  sentinel 向 Master/Slave 发送 SUBSCRIBE 命令，与 2 类似（这次有了Slave节点）。如果之前已有的连接正常，则不会再次重复连接，因此正常情况下这一步只会连接新加入的Slave节点。
  •  sentinel 向 Master/Slave 发送INFO命令，与 3 类似。
  •  sentinel 向 Master/Slave 发送PUBLISH命令，扩散消息（当前Sentinel/Master 信息 ）。sentinel 接收到了 Master/Slave 中 Hello Channel 中的消息，得到其他的Sentinel 信息，然后保存到对应Master 下的 Sentinels 列表中。至此，整个 sentinel 结构中的节点数据基本完善。
  •  sentinel 向 Master/Slave/Sentinel 发送 PUBLISH命令，扩散消息。
    在经过多次的消息扩散之后，每个 master 下的 sentinels 列表会逐渐增多。最终，每个 sentinel 中将保存着所有 Sentinel/Master/Slave 信息，并且不断进行心跳监测，信息同步。

 哨兵领导选举机制

  • 基于Raft算法实现的选举机制
  •  拉票阶段：每个哨兵节点都希望自己成为leader
  • sentinel节点收到拉票命令后，如果没有收到或者是同意其他sentinel节点的请求，就同意该节点的请求(每个节点只有一个同意票)
  • 如果sentinel节点发现自己的票数已经超过一半的数值，那么它就成为leader，去执行故障转移
  • 投票结束后，如果超过failover-timeover时间，没进行实际的故障转移操作，则重新拉票选举

RedisMaster选举方案(从slave中选出)

  • 首先，slave节点状态： 非S_DOWN，O_DOWN，DISCONNECED 状态才能满足
    • 判断规则： (down-after-milliseconds*10)+milliseconds_since_master_is_in_SDOWN-state
    • SENTINEL slaves mymaster
  •  其次，查看优先级
    • redis.conf中的配置项：slave-prioprity值越小，优先级越高
  • 再次，数据同步情况
    • Replication offset processed
  • 最后，最小的run id
    • run id 比较方案：字典顺序，ASCII码

最终主从切换过程 

  • 针对即将成为master的slave节点，将其撤出主从集群
    • 执行命令： slaveof NO ONE
  •  针对其他slave节点，使它们成为新的master从属节点
    • 执行命令：slaveof 192.168.16.40 6381
Redis各模式运行方式及优缺点
YesPlease的博客
10-13 1458
Ｒｅｄｉｓ各模式运行方式及优缺点
Redis-哨兵监控(sentinel)
weixin_62485485的博客
08-08 2738
上述的failover操作均由sentinel自己独自完成，完全无需人工干预。
spring+redis哨兵模式-解决问题清单
tianya0138的博客
04-22 732
项目没有采用maven，所以出现版本问题需要去自己手动下载jar包才可以。 采用哨兵模式的前提是redis已经成功搭建，哨兵模式的配置非常简单，网上也有很多，不详细讲述如何搭建redis。我简单列出来一下spring的配置，本篇主要讲述配置完哨兵模式产生的问题以及解决方式。 在spring配置文件中加入 <bean id="sentinelConfiguration...
redis哨兵模式简介及其优缺点
m0_53396342的博客
04-12 1405
redis哨兵模式简介及其优缺点
一些关于redis哨兵模式的总结
weixin_43486011的博客
03-07 909
redis的哨兵模式，其实是主从模式的升级，主从模式适用于当请求量大的时候，多个从节点可以分摊主节点的请求量压力，但只有主节点可以进行存数据，从节点一般都只能苟进行取数据的操作，不过可以通过redis.conf文件里面的相关参数进行配置，设定从节点也可以进行存数据。 哨兵模式，则是在主从模式的基础上，增加了“哨兵节点”的配置（sentinel），哨兵节点不参与数据存取，它的行为正如它的名词解释，负责监控主从节点，当主节点出现宕机情况了，哨兵会判断是否将从节点推举为主节点。 具体点讲，这里的监控，其实是哨
哨兵解决的问题与原理：
weixin_43868405的博客
06-20 877
哨兵解决的问题： Redis的主从模式可以将主节点的数据改变同步给从节点，从节点就可以起到两个作用： （1）作为主节点的一个备份。一旦主节点出现了故障，不可达，从节点可以作为后备，顶上来，保证数据尽量不丢失。 （2）从节点可以扩展主节点的读能力。如果主节点撑不住大量并发的读操作，此时可以分担主节点的读能力。 主从复制也随之带来了一下几个问题： （1）一旦主节点出现了故障，需要手动的将一个从节点晋升...
Redis系列：高可用之Sentinel(哨兵模式）
JavaShark的博客
07-29 582
在实际生产环境中，服务器难免会遇到一些突发状况服务器宕机，停电，硬件损坏等等，一旦发生，后果不堪设想。哨兵模式的核心还是主从模式的演变，只不过相对于主从模式在主节点宕机导致不可写的情况下，多了探活，以及竞选机制从所有的从节点竞选出新的主节点，然后自动切换。竞选机制的实现，是依赖于在系统中启动sentinel进程，对各个服务器进行监控。Redis哨兵机制是实现Redis不间断服务的高可用手段之一。主从架构集群的数据同步，是数据可靠的基础保障；主库宕机，自动执行主从切换是服务不间断的关键支撑。...
Redis 09章——哨兵（sentinel）
weixin_74019079的博客
02-16 1039
Redis 09章——哨兵（sentinel）
Redis系列4：高可用之Sentinel(哨兵模式）
Ly768768的博客
04-21 1169
在实际生产环境中，服务器难免会遇到一些突发状况：服务器宕机，停电，硬件损坏等等，一旦发生，后果不堪设想。哨兵模式的核心还是主从模式的演变，只不过相对于主从模式在主节点宕机导致不可写的情况下，多了探活，以及竞选机制：从所有的从节点竞选出新的主节点，然后自动切换。竞选机制的实现，是依赖于在系统中启动sentinel进程，对各个服务器进行监控。Redis 哨兵机制是实现 Redis 不间断服务的高可用手段之一。主从架构集群的数据同步，是数据可靠的基础保障；主库宕机，自动执行主从切换是服务不间断的关键支撑。
spring集成redis哨兵slave写问题解决
进击的Coder，Fighting！
02-21 3362
redis哨兵实现读写分离和高可靠，使用过程中是不是会出现两种问题，一种是会报socket reset异常考虑分析可能是master节点故障，客户端仍然连接旧的master; 一种是报slave写错误，考虑是故障节点重启后，仍然往旧的master中写数据。 单独写了测试类复现分析这个头疼的问题。 架构 Client： spring data redis、 jedis Redis 3台，1台mas...
redis哨兵模式
qq3073959033的博客
10-25 775
redis哨兵模式
redis哨兵模式所遇到的问题
西北的博客
06-11 5082
1.主从无法切换 检查配置文件 ： 一、确保sentinel.conf配置文件不是完全拷贝的，这个文件会在运行之后自动添加一些数据，导致拷贝之后没有删除无法自动切换主从， 二、确保 redis.conf中两个属性 requirepass masterauth 这两个密码配置都有 ，sentinel.conf中 sentinel auth-pass mymaster (passwor...
哨兵模式遇到的问题
wowlol的博客
01-09 854
1.哨兵模式在故障转移发生后，新的master产生，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变。以前的master只能现在只能当slave。 2.Sentinel作用： 1）Master状态检测 2）如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。 3）Master-Slave切换后，master_redis.conf、slave_redis.co
Redis3.2.x-哨兵模式以及遇到的问题
Howinfun的博客
08-13 3257
有了主从复制的实现以后，我们如果想对主从服务器进行监控，那么在Redis2.6以后提供了一个“哨兵”机制，在2.6版本中的哨兵为1.0版本，并不稳定，会出现各种各样的问题。在2.8以后的版本的哨兵功能就稳定起来了。 哨兵的含义就是监控Redis系统的运行状况，其主要功能有两点： 1、监控主数据库和从数据库是否正常运行 2、主数据库出现故障后，可以自动将从数据库转换为主数据库，实现自动切换 ...
redis哨兵模式出现的问题总结
qq_53698725的博客
12-05 4393
redis哨兵模式
一文读懂Redis的哨兵机制
qq_41066066的博客
08-01 565
大家好，我是memo，这几天正在看<<Redis设计与实现>>这本书籍，看到了哨兵机制这块知识点，相信大家在面试中或多或少都会遇到。为此，我做了小笔记，巩固知识。 什么是哨兵机制 哨兵机制（sentinel） 是Redis解决高可用的一种解决方案：它是由一个或者多个sentinel 实例组成的一个sentinel 系统。如图所示： 上图显示sentinel系统监控着master节点和slave节点，并且slave节点与master节点存在数据复制功能。那么问题来了： sent.
Redis哨兵详解
qq_43187430的博客
10-17 562
实现故障恢复自动化：详解Redis哨兵技术 原文出处： http://www.redis.cn/articles/20181020001.html 在前面分享的《读完这篇文章，就基本搞定了Redis主从复制》中我们曾提到，Redis主从复制的作用有数据热备、负载均衡、故障恢复等；但主从复制存在的一个问题是故障恢复无法自动化。本文将要介绍的哨兵，它基于Redis主从复制，主要作用便是解决主节点故障恢复的自动化问题，进一步提高系统的高可用性。 **注：**本文内容基于Redis 3.0版本。 一、作用和架构 1
redis 学习笔记(4)-HA高可用方案Sentinel配置
weixin_34015336的博客
11-21 369
上一节中介绍了master-slave模式，在最小配置：master、slave各一个节点的情况下，不管是master还是slave down掉一个，“完整的”读/写功能都将受影响，这在生产环境中显然不能接受。幸好redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决 每个sentinel...
详解redis的主从、哨兵和集群模式
最新发布
04-10
<think>嗯，用户想了解Redis的主从复制、哨兵机制和集群模式的工作原理和配置方法。首先，我需要回顾一下这些概念的基本原理，确保自己理解正确。主从复制主要是数据冗余和读写分离，哨兵负责高可用，集群则是数据分片和负载均衡。 主从复制的部分，我记得主库可以写，从库只能读。复制过程应该是异步的，主库将写操作传播给从库。需要说明配置方法，比如slaveof命令或者配置文件中的slaveof选项。还有持久化的问题，主库是否要开启持久化来避免重启后数据丢失，导致从库被清空？引用[1]提到了主库是否开启持久化的问题，这里需要强调推荐开启。 然后是哨兵机制，主要作用是监控主从节点，自动故障转移。用户可能想知道哨兵如何检测主库下线，如何进行投票切换。配置方面，sentinel.conf的配置参数，比如监控的主节点、quorum数量、认证密码等。引用[3]中有配置示例，可以结合说明。哨兵模式下客户端如何连接，比如通过哨兵获取主节点地址，这里可能需要提到Python客户端的示例。 集群模式方面，Redis Cluster的数据分片是使用哈希槽，每个节点负责一部分槽。配置集群需要多个节点，使用cluster meet命令或者配置文件中的集群选项。需要解释如何分配槽位，以及节点故障时的处理机制，比如主节点故障时从节点提升为主节点。 用户可能还关心这些机制之间的区别和应用场景。比如主从复制适合读写分离，哨兵提高可用性，集群解决大数据量和高并发。配置步骤要分点说明，可能包括命令和配置文件两种方式，以及常见问题，比如复制延迟、哨兵的选举过程、集群的节点扩容等。 需要检查引用内容是否准确。引用[1]和[2]讨论了主从复制和哨兵的基本架构和配置步骤，引用[3]提供了哨兵配置的具体示例。确保回答中引用的部分正确对应，比如主库持久化的重要性来自引用[1]，哨兵配置文件参考引用[3]。 用户的问题可能还涉及到实际配置中的细节，比如如何设置认证密码，如何处理网络分区，或者性能调优。不过根据问题，主要需要详细的工作原理和配置方法，可能不需要深入调优。但相关问题可以引导用户进一步思考，比如性能分析、优化方法、应用场景等，类似示例中的快速排序问题。 最后，确保回答结构清晰，分点说明每个机制的工作原理、配置步骤和常见问题，并附上相关问题供用户参考。同时，注意使用正确的中文术语，避免技术术语错误，比如“主从复制”而非“主备复制”，正确使用LaTeX格式，如配置项用代码块，数学表达式用$...$等。</think>### Redis主从复制、哨兵机制与集群模式详解 #### 一、主从复制（Replication） **工作原理** 主从复制通过数据冗余实现读写分离与容灾备份。主库（master）负责写操作，从库（slave）异步复制主库数据并支持读操作[^1]。 1. **复制流程**： - 从库发送`SYNC`命令请求同步数据。 - 主库生成RDB快照并发送给从库。 - 从库加载RDB后，主库持续推送写命令（基于AOF缓冲区）。 2. **配置方法**： - **命令行**：`SLAVEOF <master_ip> <master_port>`（从库执行）[^2]。 - **配置文件**： ```conf # 从库配置 replicaof 127.0.0.1 6379 masterauth 123456 # 主库密码 ``` **常见问题** - **数据不一致**：异步复制可能导致从库数据延迟，可配置`min-replicas-max-lag`限制最大延迟[^1]。 - **主库持久化**：建议主库开启RDB/AOF，避免重启后空数据覆盖从库[^1]。 --- #### 二、哨兵机制（Sentinel） **工作原理** 哨兵用于监控主从节点并自动故障转移，保障高可用性。 1. **功能**： - 监控节点状态（每秒`PING`检测）。 - 主库故障时，选举新主库并通知从库切换。 - 提供客户端服务发现接口。 2. **配置方法**： ```conf # sentinel.conf port 26379 sentinel monitor redis-master 127.0.0.1 6379 2 # 监控主库，2为quorum值 sentinel auth-pass redis-master 123456 # 主库密码 sentinel down-after-milliseconds redis-master 3000 # 超时判定下线[^3] ``` **常见问题** - **脑裂问题**：网络分区可能导致多主库，需配置`min-slaves-to-write`限制写入条件[^1]。 - **客户端适配**：客户端需通过哨兵获取主库地址，例如Python： ```python from redis.sentinel import Sentinel sentinel = Sentinel([('127.0.0.1', 26379)], socket_timeout=0.1) master = sentinel.master_for('redis-master', password='123456') ``` --- #### 三、集群模式（Cluster） **工作原理** Redis Cluster通过分片（16384个哈希槽）实现水平扩展与负载均衡。 1. **数据分布**： - 键通过CRC16算法映射到哈希槽。 - 每个节点负责部分槽，支持动态扩缩容。 2. **配置方法**： - 启动多个节点并启用集群模式： ```conf # redis.conf cluster-enabled yes cluster-config-file nodes.conf ``` - 构建集群： ```bash redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... --cluster-replicas 1 ``` **常见问题** - **节点故障**：从节点自动接替故障主节点（需至少一个从节点）。 - **跨槽操作**：多键操作需使用`{}`强制哈希标签，例如：`{user}:1`和`{user}:2`[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值