Redis基础

上一篇我们成功搭建了Redis主从复制架构，实现了读写分离和数据多副本备份，解决了单机Redis的性能瓶颈和单点故障隐患。但主从架构存在一个致命短板：主节点宕机后，需要手动切换从节点为主节点，人工干预效率低、容易延误业务，无法满足生产级高可用要求。

这时候就需要Redis哨兵（Sentinel）登场，它是Redis官方提供的高可用监控组件，能自动监控主从节点状态、故障自动切换、节点状态通知，彻底实现Redis集群无人值守。本篇就从零搭建一主一从三哨兵集群，全程实操、避坑满满，新手跟着步骤就能落地生产级高可用架构。

哨兵核心作用：监控（Monitoring）、自动故障转移（Automatic Failover）、通知（Notification）、配置提供者（Configuration Provider），相当于Redis集群的“监控管家”，主节点挂了立刻选新主，全程无感切换。

一、Redis哨兵核心原理

1. 哨兵基础认知

  • 哨兵本身是独立的Redis进程，不存储业务数据，只负责监控主从节点
  • 生产环境必须部署奇数个哨兵节点（3/5/7），通过投票机制判定主节点故障，避免脑裂
  • 哨兵集群互相通信，监控同一个主节点，实现分布式监控

2. 哨兵工作流程（白话版）

  1. 哨兵定时向主节点、从节点发送心跳包，检测节点存活状态
  2. 当主节点连续心跳超时，哨兵将其标记为主观下线（SDOWN）
  3. 超过半数哨兵节点判定主节点主观下线，升级为客观下线（ODOWN）
  4. 哨兵集群发起投票，选举出领头哨兵（Leader）
  5. 领头哨兵从从节点中筛选最优节点（数据最新、优先级高），升级为新主节点
  6. 修改其余从节点的复制指向，同步新主节点数据
  7. 通知客户端新主节点地址，完成无感故障切换

3. 哨兵模式核心优势

  • 自动监控：7×24小时监控主从节点存活状态
  • 自动切换：主节点故障，秒级切换新主节点，无需人工干预
  • 集群容错：支持哨兵节点单点故障，不影响整体监控
  • 配置通知：实时推送最新主节点地址给客户端

二、搭建前准备：环境规划

沿用前篇一主一从架构，新增3个哨兵节点（同一台服务器可通过端口区分，生产推荐部署在不同服务器），IP+端口规划如下：

节点类型节点角色服务器IP端口
数据节点主节点（Master）192.168.1.1006379
数据节点从节点（Slave）192.168.1.1016379
哨兵节点哨兵1192.168.1.10026379
哨兵节点哨兵2192.168.1.10126379
哨兵节点哨兵3192.168.1.10026380

前置条件：主从复制已正常运行、数据同步无误；服务器防火墙开放6379、26379、26380端口；主从节点密码一致。

三、哨兵配置文件编写

Redis安装目录自带sentinel.conf配置文件，复制三份分别配置不同哨兵，核心配置参数一致，仅端口区分。

1. 基础配置（以哨兵1：26379为例）

# 进入Redis目录
cd /usr/local/redis
# 复制默认配置
cp sentinel.conf sentinel_26379.conf
# 编辑配置
vim sentinel_26379.conf
# 监听端口
port 26379
# 后台守护进程运行
daemonize yes
# 进程PID文件
pidfile /var/run/redis-sentinel_26379.pid
# 日志文件
logfile "/var/log/redis-sentinel_26379.log"
# 工作目录
dir "/tmp"

# 核心监控配置（关键参数）
# sentinel monitor 自定义主节点名 主节点IP 主节点端口 判定故障票数
sentinel monitor mymaster 192.168.1.100 6379 2

# 主节点密码（必须与Redis主节点一致）
sentinel auth-pass mymaster 123456

# 主节点心跳超时时间（毫秒），5秒无响应判定主观下线
sentinel down-after-milliseconds mymaster 5000

# 故障切换超时时间（毫秒）
sentinel failover-timeout mymaster 15000

# 并行同步从节点数量（1即可）
sentinel parallel-syncs mymaster 1

2. 快速配置其余哨兵

复制配置文件，修改port、pidfile、logfile即可，其余参数保持一致：

  • 哨兵2（26379）：仅修改端口为26379，部署在192.168.1.101
  • 哨兵3（26380）：修改端口为26380，其余参数同哨兵1

四、启动哨兵集群

分别在对应服务器启动三个哨兵节点，启动命令通用：

# 启动哨兵节点（指定配置文件）
redis-sentinel /usr/local/redis/sentinel_26379.conf
redis-sentinel /usr/local/redis/sentinel_26379.conf  # 101服务器哨兵2
redis-sentinel /usr/local/redis/sentinel_26380.conf  # 哨兵3

启动后检查哨兵进程，确认运行正常：

ps -ef | grep sentinel

五、哨兵集群验证

1. 查看哨兵监控状态

# 连接哨兵节点
redis-cli -p 26379
# 查看监控的主节点信息
sentinel master mymaster
# 查看从节点信息
sentinel slaves mymaster
# 查看哨兵集群节点
sentinel sentinels mymaster

2. 故障切换测试（核心验证）

  1. 手动停止主节点Redis：systemctl stop redis
  2. 等待5秒（超时时间），查看哨兵日志：tail -f /var/log/redis-sentinel_26379.log
  3. 日志出现failover关键字，代表开始自动切换
  4. 切换完成后，查看新主节点：sentinel master mymaster，IP已变为从节点地址
  5. 重启原主节点，它会自动变为新主节点的从节点

切换过程无人工干预、业务无感，代表哨兵模式搭建成功！

六、哨兵常用运维命令

# 查看主节点详情
sentinel master 主节点名

# 查看从节点列表
sentinel slaves 主节点名

# 查看哨兵节点列表
sentinel sentinels 主节点名

# 手动触发故障切换
sentinel failover 主节点名

# 检查哨兵集群状态
sentinel ckquorum 主节点名

七、哨兵模式常见坑与避坑指南

1. 哨兵无法检测主节点

  • 原因：防火墙未放行端口、主节点密码配置错误、sentinel monitor参数写错
  • 解决：核对端口、密码、IP配置，放行防火墙规则

2. 故障切换失败

  • 原因：哨兵票数不足（必须≥半数）、从节点数据同步异常
  • 解决：部署奇数哨兵、确保主从数据正常同步

3. 脑裂问题

  • 原因：网络分区导致多主节点并存
  • 解决：部署至少3个哨兵、合理设置down-after-milliseconds、确保网络稳定

4. 客户端连接失败

  • 解决：客户端通过哨兵获取主节点地址，不要直连主节点固定IP

八、生产环境优化建议

  • 哨兵部署：3个哨兵分散在不同服务器，避免单点故障
  • 超时参数：down-after-milliseconds设为3-5秒，兼顾灵敏度与稳定性
  • 日志监控：配置哨兵日志告警，及时感知节点故障
  • 密码安全：主从+哨兵使用强密码，禁止公网暴露端口
  • 客户端适配：使用支持哨兵模式的Redis客户端（如Jedis、Lettuce）

总结

本篇我们完成了Redis哨兵模式的搭建、验证与故障切换测试，彻底解决了主从架构手动切换的痛点，实现了Redis集群自动监控、自动故障转移，达到了生产级高可用标准。哨兵模式是中小规模Redis集群的首选高可用方案，性价比极高。

主从+哨兵能解决高可用问题，但面对海量数据、高并发写入，单机主节点仍有存储和性能瓶颈。

发表回复