Pinxian Li1. Redis主从集群与哨兵架构概述
Redis作为高性能的内存数据库，在生产环境中通常需要部署集群来保证高可用性。今天我要分享的是一个经典的两节点Redis高可用方案：1主1从+3哨兵的部署模式。这种架构虽然服务器数量不多，但已经能够满足中小型业务对Redis高可用的基本需求。
为什么选择这种架构？首先，两台服务器保证了数据有完整备份（主从复制），而三个哨兵进程（Sentinel）则构成了最小的高可用决策单元。哨兵数量必须是奇数，这是为了保证在节点故障时能够做出明确的故障转移决策。你可能会有疑问：三个哨兵能否都部署在同一台机器上？理论上可以，但这样会失去高可用意义——如果这台机器宕机，哨兵系统就完全失效了。
在实际部署中，我建议将三个哨兵分散部署：两个放在主从节点上，第三个可以部署在独立的监控节点或业务服务器上。这样即使某个节点完全宕机，哨兵集群仍然能够正常工作。下面这张表格对比了不同哨兵部署方案的特点：
| 部署方案 | 可靠性 | 资源占用 | 管理复杂度 |
|---|---|---|---|
| 3哨兵集中部署 | 低 | 低 | 简单 |
| 2+1分散部署 | 中 | 中 | 中等 |
| 全独立部署 | 高 | 高 | 复杂 |
提示：哨兵数量建议至少3个，生产环境推荐5个。虽然3个已经能满足基本需求，但更多哨兵可以提高决策的可靠性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与Redis安装
2.1 服务器规划
假设我们有两台服务器：
- 服务器A：192.168.1.101（计划作为主节点）
- 服务器B：192.168.1.102（计划作为从节点）
每台服务器的Redis哨兵将监听26379端口。在实际操作前，请确保：
- 服务器间网络互通，防火墙已开放6379（Redis）和26379（Sentinel）端口
- 服务器时间同步（使用NTP服务）
- 系统资源充足（建议至少2GB空闲内存）
2.2 Redis安装步骤
在两台服务器上执行相同的安装操作：
bash复制# 安装依赖
sudo apt-get update
sudo apt-get install -y build-essential tcl
# 下载并编译Redis（以6.2.6版本为例）
wget https://download.redis.io/releases/redis-6.2.6.tar.gz
tar xzf redis-6.2.6.tar.gz
cd redis-6.2.6
make && sudo make install
# 创建配置目录
sudo mkdir /etc/redis
sudo cp redis.conf /etc/redis/
sudo cp sentinel.conf /etc/redis/
安装完成后，可以通过redis-server -v验证版本。这里有个小技巧：编译时如果遇到错误，可以尝试先执行make distclean再重新编译。
3. Redis主从配置详解
3.1 主节点配置（服务器A）
编辑/etc/redis/redis.conf，关键配置如下：
conf复制bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis_6379.log"
dir /var/lib/redis/6379
appendonly yes
appendfsync everysec
requirepass your_strong_password
masterauth your_strong_password
启动主节点：
bash复制sudo redis-server /etc/redis/redis.conf
3.2 从节点配置（服务器B）
从节点的配置与主节点类似，但需要添加：
conf复制replicaof 192.168.1.101 6379
replica-read-only yes
启动从节点后，可以通过以下命令验证主从状态：
bash复制redis-cli -a your_strong_password info replication
正常输出应显示：
code复制# Replication
role:slave
master_host:192.168.1.101
master_port:6379
master_link_status:up
注意：如果主从连接失败，检查防火墙设置和密码配置。我遇到过因为SELinux导致连接失败的情况，临时解决方案是
setenforce 0。
4. 哨兵系统部署
4.1 哨兵配置
在三台机器上配置哨兵（以服务器A为例）：
conf复制port 26379
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel auth-pass mymaster your_strong_password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
关键参数说明：
down-after-milliseconds：判定节点不可用的超时时间（毫秒）failover-timeout：故障转移超时时间parallel-syncs：故障转移后同时同步的从节点数
启动哨兵：
bash复制redis-sentinel /etc/redis/sentinel.conf
4.2 哨兵部署策略
建议的部署方案：
- 服务器A：Redis主节点 + 哨兵1
- 服务器B：Redis从节点 + 哨兵2
- 第三方服务器：哨兵3
这样即使某台Redis服务器完全宕机，哨兵集群仍能正常工作。通过redis-cli -p 26379 sentinel masters可以查看哨兵监控状态。
5. 故障转移测试与验证
5.1 模拟主节点故障
- 在主节点执行
DEBUG SEGFAULT强制崩溃 - 观察哨兵日志：
code复制+sdown master mymaster 192.168.1.101 6379 +odown master mymaster 192.168.1.101 6379 #quorum 2/2 +try-failover master mymaster 192.168.1.101 6379 +vote-for-leader ... +failover-state-select-slave master mymaster 192.168.1.101 6379 +failover-state-send-slaveof-noone ... +switch-master mymaster 192.168.1.101 6379 192.168.1.102 6379
5.2 验证故障转移
-
检查新的主节点：
bash复制
redis-cli -a your_strong_password -h 192.168.1.102 info replication应显示
role:master -
当原主节点恢复后，它会自动成为新主节点的从节点
6. 生产环境优化建议
6.1 性能调优参数
conf复制# 主节点
repl-backlog-size 64mb
repl-backlog-ttl 3600
client-output-buffer-limit slave 256mb 64mb 60
# 从节点
repl-ping-slave-period 10
repl-timeout 60
6.2 监控与告警
建议监控以下指标：
- 主从延迟（
master_repl_offset与slave_repl_offset差值） - 哨兵投票状态
- Redis内存使用率
可以使用Prometheus + Grafana配置监控面板，关键指标包括：
- Redis_up
- Redis_connected_slaves
- Redis_master_link_up
- Redis_used_memory
7. 常见问题排查
7.1 主从同步失败
典型错误：MASTER <-> REPLICA sync started with non empty DB
解决方案：
- 确保从节点数据目录为空
- 检查主从密码一致性
- 验证网络连接：
bash复制
telnet 192.168.1.101 6379
7.2 哨兵无法达成共识
可能原因：
- 哨兵节点间网络不通
- 系统时间不同步
- 配置文件中
sentinel monitor的quorum值设置过高
检查命令：
bash复制redis-cli -p 26379 sentinel ckquorum mymaster
8. 维护与管理技巧
-
安全重启主节点：
bash复制
redis-cli -a your_strong_password DEBUG SLEEP 30这会给哨兵足够的时间检测主节点下线，避免不必要的故障转移
-
配置持久化：
修改哨兵配置后，执行：bash复制
redis-cli -p 26379 sentinel flushconfig -
批量操作：
使用redis-cli --cluster命令管理多节点：bash复制
redis-cli --cluster call 192.168.1.101:6379 info memory
这套1主1从+3哨兵的架构，我在多个生产环境中部署过，稳定性相当不错。虽然不如官方Cluster方案强大，但对于大多数中小规模应用已经足够。关键是要确保哨兵部署的合理性和网络可靠性。在实际运维中，建议定期进行故障转移演练，确保整套系统在真正出现故障时能够按预期工作。