2841 积分	1 好友	394 主题

发消息

手把手教你部署Redis哨兵集群，实现高可用（Redis 5.0/6.0）

发表于 8 小时前 | 查看: 0| 回复: 0

数据库是应用系统最重要的资产之一。在众多数据库技术中，Redis以其高性能和丰富的数据结构著称。本文将聚焦于如何通过部署哨兵（Sentinel）集群来为Redis服务提供高可用保障。

在了解哨兵原理之后，本小节将通过实际操作，搭建一个高可用的Redis哨兵集群。

架构设计

我们采用一主两从的经典架构，并部署三个哨兵节点进行监控。主从集群的搭建可参考相关教程，搭建成功后，在Master节点执行 info replication 命令，应能看到类似以下输出：

# Replication
role:master
connected_slaves:2
min_slaves_good_slaves:2
slave0:ip=192.168.31.196,port=6379,state=online,offset=85,lag=1
slave1:ip=192.168.31.197,port=6379,state=online,offset=85,lag=2
master_repl_offset:85
repl_backlog_active:1
repl_backlog_size:268435456
repl_backlog_first_byte_offset:2
repl_backlog_histlen:84

部署哨兵

哨兵配置文件在三个节点上基本一致，主要区别在于 bind 参数需要修改为当前节点的IP地址。请注意：哨兵启动后，会自动修改配置文件中的部分运行时信息。

以下是哨兵配置文件 /etc/redis-sentinel.conf 的核心内容示例：

# 哨兵端口
port 26379

# 后台运行
daemonize yes

# 日志文件
logfile "/var/log/redis/sentinel.log"

# 工作目录
dir "/tmp"

# 监控的主节点信息：
# mymaster：主节点名称（可自定义）
# 192.168.31.195 6379：主节点地址和端口
# 2：quorum值（至少需要2个哨兵同意才能判定客观下线）
sentinel monitor mymaster 192.168.31.195 6379 2

# 主节点密码（如果设置了requirepass）
sentinel auth-pass mymaster your_redis_password

# 主观下线时间（毫秒）
sentinel down-after-milliseconds mymaster 5000

# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 60000

# 并行同步的从节点数量
sentinel parallel-syncs mymaster 1

# 绑定IP（改为当前节点的IP）
bind 192.168.31.195

启动哨兵

如果通过yum等包管理器安装的Redis，通常会附带哨兵服务，可以直接使用systemctl管理。

systemctl start redis-sentinel
systemctl enable redis-sentinel

查看哨兵信息

启动后，可以通过以下命令连接到任意哨兵节点查看状态：

redis-cli -h 192.168.31.195 -p 26379 info

在输出信息中，找到 Sentinel 部分，可以看到类似以下内容，表明哨兵已成功监控到1个主节点，该主节点有2个从节点，并且集群中有3个哨兵节点。

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.31.195:6379,slaves=2,sentinels=3

宕机测试与故障转移

现在，让我们模拟主节点宕机，来验证哨兵（Sentinel）集群的自动故障转移能力。你可以通过观察哨兵的日志文件（如 /var/log/redis/sentinel.log）来了解完整的选举过程。日志中会记录从客观下线判定到新主节点切换的全过程，下面是一个简化的示例：

1137:X 18 Jan 23:32:26.642 # -odown master mymaster 192.168.31.195 6379
...
1137:X 18 Jan 23:33:25.601 # +switch-master mymaster 192.168.31.195 6379 192.168.31.196 6379
1137:X 18 Jan 23:33:25.601 * +slave slave 192.168.31.197:6379 192.168.31.197 6379 @ mymaster 192.168.31.196 6379
1137:X 18 Jan 23:33:25.601 * +slave slave 192.168.31.195:6379 192.168.31.195 6379 @ mymaster 192.168.31.196 6379

从日志可以看到，主节点已从 192.168.31.195 切换到了 192.168.31.196。这个过程实际上隐藏了一个需要注意的“坑”，你发现了吗？