当前位置: 首页 > java >正文

【Redis】redis主从哨兵

Redis 主从复制

在访问量极高的场景下,单台 Redis 已难以承载所有请求,且单点故障风险高。通过主从复制,可以实现读写分离、数据备份与高可用。

概念

  • 主节点(Master):负责写操作,将数据变更同步给从节点。
  • 从节点(Slave/Replica):负责读操作,自动从主节点拉取最新数据。

优势

  • 性能提升:读请求分摊到多个从节点
  • 数据备份:从节点持有一份完整数据副本
  • 读写分离:写入在主节点,读取在从节点
  • 提高可靠性:主节点故障后,从节点仍可提供读取服务

搭建主从复制集群

可以用两台机器,也可在一台机器上启动多个 Redis 实例,只需用不同配置文件。

通用配置(主从共用)

requirepass 123456
loglevel notice
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis/redis6379.log"
dbfilename dump.rdb
dir /var/lib/redis-slave6379
bind 0.0.0.0
port 6379
daemonize yes

从节点额外配置

masterauth 123456
replicaof 192.168.100.30 6379
  1. 先启动主节点,再启动从节点。

  2. 验证主从状态:

    # 主节点
    192.168.100.30:6379> info replication
    role:master
    connected_slaves:2
    ...# 从节点
    192.168.100.200:6389> info replication
    role:slave
    master_host:192.168.100.30
    master_link_status:up
    ...
    
  3. 测试读写

    • 主节点:可读可写
    • 从节点:只读,写入会报 READONLY You can't write against a read only replica.
  4. 断线重连
    如果从节点短暂断开,重新上线后会自动补同步这段时间的所有数据,不会丢失。

  5. 故障恢复
    主节点宕机,从节点不会自动“上位”。需人工或由哨兵进行故障转移。


主从从拓扑

当主节点被大量从节点挂载压力过大时,可使用“主→从→从”多级复制。

# 从节点命令示例,将当前实例从现有主切到新的主
192.168.100.200:6389> SLAVEOF 192.168.100.200 6379

注意:多级复制会引入更高的延迟。


退出从模式(无停机)

如果临时需要让某个从节点切换为主:

192.168.100.200:6389> SLAVEOF no one
OK
192.168.100.200:6389> info replication
role:master
connected_slaves:0
...

日志中会看到从节点断开主节点连接并开启主模式的记录。


主从复制工作流程

  1. 从节点启动 → 连接主节点 → 发送 SYNC(或 PSYNC)命令
  2. 主节点
    • 收到同步请求后后台生成一次完整的 RDB 快照
    • 将快照数据发送给从节点
    • 在生成快照期间及之后,将新的写命令缓存在内存并实时转发给从节点
  3. 心跳
    • 默认每 10 秒发送一次 PING 确保主从连接正常,可通过 repl-ping-replica-period 调整

Redis 哨兵(Sentinel)

Sentinel 负责监控主从集群健康,自动故障转移并通知客户端。

Sentinel 核心功能

  • 主从监控:实时检测主、从节点是否可用
  • 故障通知:将故障及切换结果告知客户端
  • 自动故障转移:主节点挂掉时,选举新的主节点并重配置所有从节点
  • 配置中心:自动更新 Redis 和 Sentinel 的配置文件

部署示例

  1. 准备一主二从,分别启动:

    redis-server /etc/redis6379.conf   # 主
    redis-server /etc/redis6389.conf   # 从1
    redis-server /etc/redis6399.conf   # 从2
    
  2. 配置并启动三台 Sentinel(建议奇数台):

    bind 0.0.0.0
    protected-mode no
    port 26379
    daemonize yes
    pidfile /var/run/redis-sentinel26379.pid
    logfile "/redisdata/sentinel26379.log"
    dir /redisdatasentinel monitor mymaster 192.168.100.131 6379 2
    sentinel auth-pass mymaster 123456
    

    启动命令任选其一:

    redis-sentinel /etc/sentinel26379.conf
    # 或
    redis-server /etc/sentinel26379.conf --sentinel
    
  3. 查看 Sentinel 日志,确认监控已生效。


故障转移流程

  1. 主观宕机判断(Sentinel 认为主不可达),标记 +sdown
  2. 投票:至少 quorum 台 Sentinel 同意
  3. 客观宕机确认,标记 +odown
  4. 配置更新:Sentinel 更新自身及 Redis 实例配置
  5. 切换主节点+switch-master
  6. 旧主恢复:如果旧主重启,按配置会被设为从节点,不再自动成为主
186501:X 19 Apr 2025 12:13:52.675 # +sdown master mymaster 192.168.100.30 6379
186501:X 19 Apr 2025 12:13:52.736 # +new-epoch 1
186501:X 19 Apr 2025 12:13:52.737 # +vote-for-leader 8e9617be2327ed19c589ee819bc725eb892ad700 1
186501:X 19 Apr 2025 12:13:52.747 # +odown master mymaster 192.168.100.30 6379 #quorum 3/2
186501:X 19 Apr 2025 12:13:53.874 # +switch-master mymaster 192.168.100.30 6379 192.168.100.200 6389

这些日志行展示了完整的故障转移过程:

  1. 首先检测到主节点宕机(+sdown)
  2. 开始新的选举周期(+new-epoch)
  3. 投票给指定的哨兵领导者(+vote-for-leader)
  4. 确认主节点客观宕机(+odown)
  5. 最终完成主节点切换(+switch-master),将主节点从192.168.100.30:6379切换到192.168.100.200:6389

常见问题排查

  1. 网络连通:防火墙、端口、SELinux 是否放行/关闭
  2. 认证密码:主从与 Sentinel 之间密码需一致
  3. 日志检查:从节点或 Sentinel 日志中有无错误提示
  4. 资源瓶颈:Redis 实例的 CPU、内存、磁盘 IO 是否到达上限

小贴士:生产环境中建议结合 Redis Cluster 或者更完善的高可用方案,根据业务需求选择合适的架构。

http://www.xdnf.cn/news/1486.html

相关文章:

  • MySQL常见问题解答
  • 【异常解决】Spring Boot 返回排序后的 Map 但前端接收顺序不对的解决方案
  • C++类与继承
  • SpringBoot中6种自定义starter开发方法
  • 同z科技面经
  • Python爬虫第18节-动态渲染页面抓取之Splash使用上篇
  • Sci期刊的编辑会对投稿论文进行查重吗?
  • 【深度学习与大模型基础】第13章-什么是机器学习
  • CSGO 盲盒开箱系统技术实现深度解析
  • Spring Boot + MyBatis 动态字段更新方法
  • ToDesk远程开机设置指南(适用于HP台式机)
  • 网络安全零基础培训 L1-7 Web基础和CSS渲染
  • C++入门小馆: 探寻vector类
  • 配置 Nginx 的 HTTPS
  • 【已解决】Chrome开发工具栏无法看到React Developer Tools
  • Visium HD多样本拼片拆分
  • 基于 Skynet Cluster 模式的完整案例
  • 【TUST“码蹄杯”编程之星】4.23 每日一题
  • Spring Boot 请求参数接收控制指南
  • 有源晶振波形特性与测量分析
  • 【Deepseek学习大模型推理】MOONCAKE: A KVCache-centric Architecture 第一部分引言部分
  • Java 异常 SSLException: fatal alert: protocol_version 全解析与解决方案
  • 多智能体系统的中间件架构
  • 爬虫学习总结
  • 02.Python代码Pandas - Series全系列分享(使用.特点.说明.取值.函数)
  • AIGC vs 人类创作者:是竞争还是协作?
  • Python基础语法3
  • 模型量化核心技术解析:从算法原理到工业级实践
  • ActiveMQ 核心概念与消息模型详解(一)
  • 巴西快手kwai短视频广告代投游戏出海营销攻略