redis主从复制配置

Redis主从复制配置是保障数据高可用最直接的手段，核心就三步：配主节点、配从节点、检查状态。 实践中我们接触过非常多因为配置细节没到位导致同步中断的场景，这篇文章把Master和Slave两端该改的配置、该敲的命令、该避开的坑一次性说清楚。

Redis主从复制配置详解：从零搭建一主一从

日常开发中,单机Redis最让人头疼的不是慢，而是它挂了之后整个业务缓存全打回数据库，主从复制解决的就是这个问题，它的原理并不复杂：从节点主动找主节点建立连接，主节点把全量数据同步给从节点，之后每个写命令都会实时推送给从节点，我们一步步来实操。

主节点Master需要改哪些配置

主节点相对简单,重点是开启持久化和设置密码。

• 打开redis.conf，把daemonize改为yes，让Redis在后台运行
• 设置requirepass指定Master的密码，例如requirepass redis@2026
• 开启AOF或RDB持久化,主从复制全量同步时需要读取磁盘上的RDB文件，持久化关闭会导致同步异常
• 确认bind配置允许从节点的内网IP访问，常见的坑是把bind锁死在0.0.1，导致从节点无法连接

修改完成后重启Redis服务：

redis-server /etc/redis.conf
redis-cli -a 'redis@2026' ping

返回PONG就表示主节点已就绪，这里提醒一句：配置requirepass后，从节点连接必须带上对应的masterauth，否则认证不通过，日志里会不停报NOAUTH。

从节点Slave如何指向主节点

从节点的配置有两种方式,改配置文件或者用命令行动态指定，生产环境建议直接改配置文件，重启后依然生效。

在从节点的redis.conf中追加以下内容：

• replicaof <主节点IP> <主节点端口>，例如replicaof 10.0.0.12 6379
• masterauth <主节点密码>，密码必须和Master的requirepass一致
• replica-read-only yes，从节点只做读操作，避免直接写从节点造成数据不一致

保存后重启从节点服务：

redis-server /etc/redis.conf
redis-cli -p 6379 info replication

如果输出中role显示为slave，并且master_link_status对应的是up，则说明主从关系已经建立，Redis 5.0之后的版本中，role:slave等价于role:replica，只是命名习惯不同。

验证主从同步状态的两个关键指标

配置完成后,光看报不报错还不够，Redis主从复制的状态信息高度集中在info replication命令的输出里，核心关注以下两个字段。

• master_link_status：主从之间的TCP链路状态，正常是up，断线时为down
• master_repl_offset和slave_repl_offset：分别代表主从的复制偏移量

手动验证同步效果时,在主节点写入数据：

redis-cli -a 'redis@2026' set user:name "test"

再到从节点读取：

redis-cli -p 6380 -a 'redis@2026' get user:name

返回test即说明数据已经成功复刻，需要留意的是，主从复制是异步的，数据从主节点到从节点存在毫秒级延迟，行业内普遍的共识是在局域网环境下复制延迟通常低于1毫秒，但跨机房部署时延迟会随网络质量波动，如果要追求强一致，可以在写入后短暂sleep再读从节点，或者通过WAIT命令阻塞等待同步数量。

Redis主从复制和哨兵有什么区别

很多人配置完主从后就觉得高可用万事大吉了,这是一个认知误区。主从复制只负责数据备份和读写分离，不负责故障转移，当主节点宕机时，从节点不会自动顶上去，对外服务依然处于不可写状态。

哨兵（Sentinel）才是解决自动故障转移的组件，它做的事情可以用一句话概括：监控主从节点的健康状态，主节点挂了自动把一个从节点提升为新的主节点，哨兵本身也要部署奇数个节点，不少于3个，否则无法在多数派选举中达成一致。

对比维度上两者差别明显：

• 数据层面：主从复制解决数据冗余，让数据有备份
• 服务层面：哨兵解决高可用，让服务在故障时不间断
• 部署成本：主从只需要两台机器，哨兵需要额外部署至少三个进程
• 适用场景：主从适合读写分离、数据灾备；哨兵适合需要自动切换的核心业务链路

建议的做法是：先做主从，再在上下层部署哨兵，进程部署在不同物理机器上，只做主从不配哨兵的方案，本质上还是裸奔。

Redis主从复制延迟怎么解决

主从复制延迟是实际运维中反馈最多的问题,从节点数据落后主节点太多，就会导致读取到的数据是旧值，延迟的根源通常出在以下几个环节：

• 网络带宽不足：主节点持续产生大量写命令，推送数据包超过从节点带宽上限
• 从节点执行慢：从节点还在处理慢查询，积压命令越来越多
• 主节点大量KEYS 操作或全量遍历导致阻塞

针对这些根源,有几种直接有效的操作：

• 为从节点适当加大client-output-buffer-limit限制，配置为replica 512mb 128mb 60
• 监控慢日志,调大slowlog-log-slower-than阈值，定位阻塞命令
• 调整主从部署在同一内网网段,避免走公网链路同步
• 从节点读多写少的需求下,升级从节点实例规格，保证处理能力大于主节点

如果延迟持续增长无法收敛,最干脆的办法是断开从节点重新全量同步，从节点执行REPLICAOF NO ONE再重新REPLICAOF <MASTER_IP> <PORT>，重新建立连接会触发一次新的RDB全量同步。

主从切换时的数据一致性问题

有些业务场景对数据一致性要求较高,会手动触发主从切换，手动切换的操作步骤有讲究，顺序错了会丢数据。

推荐的操作路径是：

• 在从节点执行REPLICAOF NO ONE，使从节点变为主节点
• 在旧主节点上执行REPLICAOF <新主IP> <新端口>，让它降级为从节点
• 检查新的主从复制状态,确认链路为up
• 业务侧读写入口切换到新的主节点

这个过程中存在一个时间窗口：旧主节点可能还有尚未推送到从节点的写缓存，因此切换前建议先暂停业务写入，等主从偏移量对齐后再操作，业内专家的实操建议是：在业务低峰期做切换，并提前在监控页面对齐两个复制偏移位点。

主从复制配置中常见的三个异常场景

主从日志反复断连重连

表现为主节点日志中出现大量MASTER <-> REPLICA sync started，然后很快超时，排障时先用ping测试主从机器之间的网络延迟，再查看主节点的listening-port是否被防火墙拦截，防火墙放行6379端口后问题基本解决。

全量同步一直不结束

主节点内存占用较大且repl-backlog-size设置过小时，从节点反复请求全量同步，此时把主节点的repl-backlog-size调大，例如增加到128mb，给断线重连留出足够缓冲空间。

主节点重启后从节点不同步

主节点关闭了持久化,重启后内存数据为空，复制流逻辑判定主节点没有数据可同步，从节点保留旧数据但不再接收更新，解决办法很简单：主节点开启RDB持久化，save策略至少保留一个dump.rdb周期，这在实际生产中发生概率很高，配置完成后建议重启主节点做一次完整验证。

主从读多写少场景的架构建议

业务侧如果大部分请求都是读操作,主从复制最大的价值在于把读流量分摊到多个从节点，但架构上有一个原则需要遵守：CPU密集型的读操作尽量放在从节点，实时性要求极高的数据读主节点，比如用户会话信息、支付状态这类数据，一致性比并发重要，优先走主节点读，文章列表、商品详情页这类缓存数据可以从从节点读取，即使延迟几毫秒也不会影响体验。

架构上按数据维度进行读写分层,远比无脑把所有请求都路由到从节点更可靠，多数情况下，一主两从已经能支撑相当规模的业务量，不建议一开始就堆大量从节点，维护成本会随节点数线性上升。

Redis主从复制常见问题解答

主从复制模式下从节点能写数据吗

从节点默认不允许写入,配置项replica-read-only是yes，此时从节点执行写命令会返回READONLY错误，如果因为特殊需要临时开启写入，注意业务侧必须自行处理数据冲突问题，否则主从数据会产生分叉。

网络断开会自动恢复吗

会,Redis主从复制支持断线增量重传机制，网络恢复后主从连接自动重建，主节点通过复制积压缓冲区把断线期间的写命令补偿给从节点，断线时间过长、超出repl-backlog-size范围时，则退化为全量同步。

主从数据能保证完全一致吗

Redis主从复制是异步协议,不保证实时一致，只保证最终一致，如果差异必须在核心链路中对业务屏蔽，可以引入Redis Cluster的同步写策略，或者使用WAIT命令等待至少一个从节点确认复制完成，从机制上把异步复制变成近乎同步复制。