01. 环境准备
在正式进入 Redis 主从复制配置与搭建实战前，我们需要明确目标：实现稳定的主从结构、可预见的延迟以及可迁移的高可用能力。核心目标是保障数据的一致性、快速故障转移以及简化运维流程。
本节聚焦于硬件与网络要求、操作系统选型与时钟同步等前置条件。一个健康的环境应具备内网低延迟、冗余存储、以及可预测的网络带宽，以支持高并发写入和复制带宽。
此外，安全边界与资源分配也是环境准备的重要组成部分。建议使用三台节点（1 主 + 2 从），布置在同一局域网或可达的VPN内，确保端口 6379（主从通信）与 26379（Sentinel）在防火墙中放行，且并发请求的 CPU、内存与 I/O 能力符合预估负载。
# 以 Debian/Ubuntu 为例，安装依赖与 Redis
sudo apt-get update
sudo apt-get install -y build-essential tcl
wget http://download.redis.io/releases/redis-7.0.0.tar.gz
tar xzf redis-7.0.0.tar.gz
cd redis-7.0.0
make
sudo make install# 使用 Redis 官方镜像进行快速环境搭建（可选）
docker pull redis:7
docker network create redis-net
docker run -d --name redis-master --net redis-net --hostname redis-master -p 6379:6379 redis:7
docker run -d --name redis-slave1 --net redis-net --hostname redis-slave1 -p 6380:6379 redis:7
在本节后继续，我们将通过实际配置来实现 Redis 的主从复制与高可用自动故障转移。为了实现高可用的自动故障转移，后续将引入 Sentinel 集群来监控主节点并在故障时自动完成故障转移。
02. 主从复制的基本搭建
01. 创建主从关系的基本步骤
在开始前，请确保两台机器的 Redis 已安装并能互相连通。核心要点是把从节点指向主节点，以建立稳定的复制通道，使从节点复制主节点的数据。
可通过命令行快速把从节点指向主节点，验证复制关系是否建立成功。复制关系建立成功后，从节点将持续从主节点拉取写操作并进行数据同步。
# 在从节点执行，指定主节点的 IP 和端口
redis-cli -h 192.168.1.102 -p 6379 replicaof 192.168.1.101 6379
# 或者在旧版本中使用 slaveof
redis-cli -h 192.168.1.102 -p 6379 slaveof 192.168.1.101 6379
如果需要回退到单机模式，可以执行 replicaof no one（或 slaveof no one），从而取消主从关系。
在实际生产环境中，master 节点应配置正确的网络访问权限与认证机制，以避免未经授权的主从切换或数据被篡改。
# 从节点 redis.conf 片段（示例）
bind 0.0.0.0
port 6379
replicaof 192.168.1.101 6379
masterauth your_master_password
requirepass your_slave_password
# 主节点 redis.conf 片段（示例）
bind 0.0.0.0
port 6379
# 无 replicaof，作为主节点
requirepass your_master_password
appendonly yes
02. 配置要点与验证
要点包括 bind、protected-mode、masterauth、以及 replicaof 的正确设置。通过日志与命令行验证复制状态，通常在从节点执行 INFO replication 能看到 role: replica 与 master_host 等字段。
在完成配置后，执行简单的写入测试以验证主从同步的可用性：向主节点写入数据，随后在从节点读取数据以确认数据一致性。
03. 持久化与安全
01. 持久化配置
为确保数据在重启后能恢复，需开启持久化机制。AOF 能提供较强的写操作持久性，RDB 则提供快速的全量快照。结合使用通常可以在数据安全与性能之间取得平衡。
在主从结构中，持久化配置应保持一致，且从节点的关联也应具备稳定的持久化策略，以避免出现长时间断线后数据丢失。
# redis.conf 常见持久化配置片段
appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000
# 如需混合模式，请在主从节点都设置相同的持久化策略
02. 安全与认证
在生产环境中，认证机制是不可忽视的一环。为避免未授权访问，建议为主从节点都设置 requirepass，并在从节点配置 masterauth，以实现从节点对主节点的认证。
还可以通过 rename-command 等安全策略对危险命令做进一步保护，降低被利用的风险。
# 从节点 redis.conf 中的安全配置片段
requirepass your_slave_password
masterauth your_master_password
rename-command CONFIG ""
rename-command SHUTDOWN ""
04. 高可用与自动故障转移
01. Sentinel 的工作原理
为实现高可用自动故障转移，Redis Sentinel 提供对主从拓扑的监控、故障判定与自动故障转移能力。Sentinel 会持续监控主节点的健康状态，一旦检测到主节点不可用，会自动选举新的主节点并通知客户端更新连接信息。
通过部署多实例的 Sentinel，可以形成一个高可用的投票系统，确保在单点故障时仍能维持系统可用性与数据可访问性。
# 安装与启动 Sentinel（示例，三节点部署）
docker run -d --name redis-sentinel-1 --net host redis:7 sh -c "redis-server /etc/redis/sentinel.conf --sentinel"
02. Sentinel 集群搭建步骤
部署时需要为每个 Sentinel 实例提供配置文件，以监控同一个 master。核心配置包括监控目标、故障判定时间与并发故障处理等。
# sentinel.conf（示例，适用于多实例部署）
port 26379
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel auth-pass mymaster your_master_password
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
在三台 Sentinel 节点同时运行后，系统会对主节点进行健康判定，并在需要时触发故障转移，自动将一个从节点晋升为新主。同时，从节点的复本关系 将被重新配置到新的主节点。
为确保故障转移顺利完成，建议在 Sentinel 集群中配置 认证、网络策略、以及对新主节点的快速发现机制，并确保应用客户端能够通过 Sentinel 组获取最新主节点信息。
# 典型 sentinel 集群的运行示例（简化）
# 三个 Sentinel 实例的配置都包含相同的 monitor 设置
# 每个实例在不同端口/主机上运行
03. 故障转移演练与验证
定期进行故障转移演练是确保高可用性的重要环节。先模拟主节点不可用，验证 Sentinel 是否能够发现故障、选举新主，并将应用的连接端点指向新主。
演练中应关注以下关键点：新主的选举速度、从新主的数据一致性、以及应用端对新主的重新发现能力。完成演练后，记录日志以便后续优化。
# 演练步骤（示例）
# 1. 停止当前主节点服务
# 2. 观察 Sentinel 的故障判定时间
# 3. 查看新的主节点信息
redis-cli -p 26379 INFO Sentinel
redis-cli -p 6379 INFO replication
05. 监控与运维
01. 监控指标与告警
有效的监控应覆盖 复制延迟、主从偏差、Sentinel 状态、以及集群的网络延迟等维度。结合告警系统，可以在延迟过高或故障转移异常时第一时间采取行动。
常见监控项包括：主从延迟、复制断连、RDB/AOF 持久化指标、Sentinel 投票状态与故障判定时间。
# 使用 Redis 内置 INFO 指令获取复制状态示例
redis-cli -h 192.168.1.101 -p 6379 INFO replication
# 获取 Sentinel 状态（需连接到 sentinel 实例）
redis-cli -p 26379 INFO Sentinel
02. 备份、恢复与容量规划
持续进行数据备份并验证恢复流程，是保障长期可用性的关键。结合 周期性快照（RDB） 与 AOF，可以实现快速恢复与最小数据损失。
容量规划方面，建议为主从结构留出冗余容量，确保高峰期的写入压力不会直接转移到单点，降低延迟并提高并发能力。
# 备份数据示例（RDB/AOF 常见做法）
cp /var/lib/redis/dump.rdb /backup/redis/dump-$(date +%F).rdb
cp /var/lib/redis/appendonly.aof /backup/redis/appendonly-$(date +%F).aof
