和县网站制作app渠道推广
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
-
先启动主节点，再启动从节点。
-
验证主从状态：
# 主节点 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 ... -
测试读写
- 主节点：可读可写
- 从节点：只读，写入会报
READONLY You can't write against a read only replica.
-
断线重连
如果从节点短暂断开，重新上线后会自动补同步这段时间的所有数据，不会丢失。 -
故障恢复
主节点宕机，从节点不会自动“上位”。需人工或由哨兵进行故障转移。
主从从拓扑
当主节点被大量从节点挂载压力过大时，可使用“主→从→从”多级复制。
# 从节点命令示例，将当前实例从现有主切到新的主
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
...
日志中会看到从节点断开主节点连接并开启主模式的记录。
主从复制工作流程
- 从节点启动 → 连接主节点 → 发送
SYNC（或PSYNC）命令 - 主节点
- 收到同步请求后后台生成一次完整的 RDB 快照
- 将快照数据发送给从节点
- 在生成快照期间及之后，将新的写命令缓存在内存并实时转发给从节点
- 心跳
- 默认每 10 秒发送一次 PING 确保主从连接正常，可通过
repl-ping-replica-period调整
- 默认每 10 秒发送一次 PING 确保主从连接正常，可通过
Redis 哨兵（Sentinel）
Sentinel 负责监控主从集群健康，自动故障转移并通知客户端。
Sentinel 核心功能
- 主从监控：实时检测主、从节点是否可用
- 故障通知：将故障及切换结果告知客户端
- 自动故障转移：主节点挂掉时，选举新的主节点并重配置所有从节点
- 配置中心：自动更新 Redis 和 Sentinel 的配置文件
部署示例
-
准备一主二从，分别启动：
redis-server /etc/redis6379.conf # 主 redis-server /etc/redis6389.conf # 从1 redis-server /etc/redis6399.conf # 从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 -
查看 Sentinel 日志，确认监控已生效。
故障转移流程
- 主观宕机判断（Sentinel 认为主不可达），标记
+sdown - 投票：至少
quorum台 Sentinel 同意 - 客观宕机确认，标记
+odown - 配置更新：Sentinel 更新自身及 Redis 实例配置
- 切换主节点，
+switch-master - 旧主恢复：如果旧主重启，按配置会被设为从节点，不再自动成为主
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
这些日志行展示了完整的故障转移过程：
- 首先检测到主节点宕机（+sdown）
- 开始新的选举周期（+new-epoch）
- 投票给指定的哨兵领导者（+vote-for-leader）
- 确认主节点客观宕机（+odown）
- 最终完成主节点切换（+switch-master），将主节点从192.168.100.30:6379切换到192.168.100.200:6389
常见问题排查
- 网络连通：防火墙、端口、SELinux 是否放行/关闭
- 认证密码：主从与 Sentinel 之间密码需一致
- 日志检查：从节点或 Sentinel 日志中有无错误提示
- 资源瓶颈：Redis 实例的 CPU、内存、磁盘 IO 是否到达上限
小贴士：生产环境中建议结合 Redis Cluster 或者更完善的高可用方案，根据业务需求选择合适的架构。