Redis 主从复制是指把一台 Redis 节点的数据异步复制到一台或多台从节点，从节点既可以作为数据副本，也可以承担读请求。搭建主从复制最直接的好处是提高读并发能力，同时让数据具备基础冗余。主节点继续处理写请求，从节点实时拉取主节点的变更，当主节点出现不可用时，至少还有从节点保留数据，方便后续切换。本文使用三台 Linux 主机搭建一主两从结构，主节点端口 6379，从节点分别使用 6380 和 6381。

一、主从复制的同步机制与准备条件

Redis 主从复制在第一次建立关系时会先尝试部分重同步，如果无法完成，则退化为全量同步。全量同步阶段，主节点执行 BGSAVE 生成 RDB 快照并发送给从节点，从节点清空自身旧数据后载入这份快照；随后主节点把生成快照期间的写命令缓存在复制积压缓冲区中，再逐条发给从节点，直到从节点追平偏移量。部分重同步依赖运行 ID 和复制偏移量，只有当从节点断线重连后对应偏移量仍然落在主节点的积压缓冲区里，才能跳过全量同步，只补发缺失的数据。

因此，搭建前需要保证主从节点版本尽量一致，至少大版本不要相差过大；网络互通，确保从节点能访问主节点的 6379 端口；主节点如果配置了 requirepass，从节点必须配置对应的 masterauth，否则握手阶段就会失败。持久化方面建议主节点开启 RDB 或 AOF，如果主节点完全禁用持久化，那么主节点重启后可能会把空数据集同步给从节点，造成数据被清空的风险。

• 三台主机或本机三个端口，网络互通。
• Redis 6.0 以上版本，编译安装或使用系统包安装。
• 主节点设置访问密码，从节点配置认证。
• 主节点保留持久化能力，避免重启后为空。

二、主从节点配置与启动步骤

先配置主节点。以下配置主要说明 bind、protected-mode、认证和持久化项，其他参数可按默认值处理。将主节点配置文件保存为 redis-master.conf，使用 redis-server 启动。注意如果 Redis 以 service 方式运行，修改后需要重启服务。

# redis-master.conf 主节点关键配置
bind 0.0.0.0
protected-mode no
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis_6379.log
dir /var/lib/redis_master
dbfilename dump.rdb
appendonly yes
appendfilename "appendonly.aof"
requirepass master123
masterauth master123

从节点配置与主节点类似，核心差异在于 replicaof 和 masterauth。replicaof 指定主节点的 IP 和端口，旧版本中的 slaveof 命令仍然可用，但推荐使用 replicaof。主节点有密码时，masterauth 必须与主节点 requirepass 保持一致，否则从节点连接后认证失败，日志中会出现 NOAUTH Authentication required。

# redis-slave1.conf 从节点1关键配置
bind 0.0.0.0
protected-mode no
port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile /var/log/redis_6380.log
dir /var/lib/redis_slave1
dbfilename dump.rdb
replicaof 192.168.10.10 6379
masterauth master123
requirepass slave123
replica-read-only yes

如果在本机模拟，可以使用同一份二进制程序启动不同端口，但要注意目录不要混用，否则 RDB 文件相互覆盖。启动第二台从节点时，把端口改成 6381，目录改成 redis_slave2，replicaof 仍然指向主节点。

# 启动主节点
redis-server /etc/redis/redis-master.conf
# 启动从节点1
redis-server /etc/redis/redis-slave1.conf
# 启动从节点2
redis-server /etc/redis/redis-slave2.conf
# 查看主节点复制状态
redis-cli -p 6379 -a master123 info replication

三、验证同步结果与故障排查

启动完成后，先通过 redis-cli 连接主节点，执行 info replication，确认角色为 master 且 connected_slaves 数量为 2。然后向主节点写入一个字符串，再连接从节点读取该键，如果能读到，说明主从链路已经打通。写入验证时可以顺便在从节点上执行 set 命令，从节点默认只读，应当提示 READONLY You can't write against a read only replica。

# 主节点写入
redis-cli -p 6379 -a master123 set site ipipp
# 从节点读取
redis-cli -p 6380 -a slave123 get site
# 从节点尝试写入，默认会触发只读错误
redis-cli -p 6380 -a slave123 set mode test

从节点的 info replication 输出中，master_link_status:up 表示主从连接正常，master_sync_in_progress:0 表示没有正在进行的全量同步。如果从节点一直显示 sync 状态，可以检查网络、主节点持久化是否卡住、主节点是否正在执行耗时操作。全量同步会影响主节点短暂的可响应性，但通常只发生在首次连接和偏移量丢失时。

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.11,port=6380,state=online,offset=1842,lag=1
slave1:ip=192.168.10.12,port=6381,state=online,offset=1842,lag=0
master_failover_state:no-failover
master_replid:8f5eef7e2b1d9a6c0f3e8b4a7d2c1f0e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1842
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1842

常见问题集中在三类：一是连接拒绝，通常由 bind、protected-mode 或防火墙引起；二是认证失败，从节点 masterauth 未配置或密码不一致；三是同步后数据仍然为空，需要确认主节点是否已经打开持久化，并且从节点 dir 目录可写。为了减少这种问题，主从复制架构中通常不建议开启从节点可写，除非明确需要向从节点写入临时数据并接受数据不一致。

四、主从复制的局限与哨兵集群演进

主从复制是 Redis 高可用方案的基础，但它只解决数据副本和读扩展问题，不解决故障自动转移。主节点宕机后，从节点依然可以读，但不会自动升级为主节点，需要人工介入将某台从节点执行 slaveof no one 并修改客户端连接地址。这一过程容易出错且恢复时间长，因此生产环境一般会用 Redis Sentinel 监控主节点，在判定主节点下线后自动选主。

此外，主从复制是异步复制，主节点返回客户端写入成功时，从节点可能还没有收到该命令。如果主节点在极短时间内宕机且没有持久化该命令，存在数据丢失窗口。对于要求强一致或写入量极大的场景，需要进一步使用 Redis Cluster 做数据分片，或调整 min-replicas-to-write 等参数降低丢失风险。

回到本文的搭建结果，主从复制已经可以提供基本的读写分离能力，也会为后续接入哨兵和集群打下基础。将当前三节点结构保留下来，下一步可以继续部署 Sentinel 来监控和自动切换，或者把业务读请求分离到从节点上，观察延迟和连接数变化。