redis 5.0主从复制需同时配置replicaof和masterauth才能稳定运行，否则info replication显示master_link_status:down；replicaof命令临时生效，写入redis.conf才永久生效；replica-read-only仅拦截直接写命令，不防lua等绕过；部分重同步依赖repl-backlog-size和repl-timeout合理设置。
Redis 5.0 主从复制本身不难配，但配置错一个字段、漏一个认证项，INFO replication 就永远显示 master_link_status:down，数据一动不动。关键不是“能不能配”，而是“配完能不能稳住”。
REPLICAOF 命令 vs 配置文件：临时改和永久生效的区别
Redis 5.0 起废弃 SLAVEOF，统一用 REPLICAOF。但命令行执行是临时的——重启从节点后配置丢失；写进 redis.conf 才是永久生效。
-
REPLICAOF 192.168.1.100 6379在 redis-cli 中执行，立即触发同步，但进程重启即失效 -
replicaof 192.168.1.100 6379必须写在从节点的redis.conf里（注意：配置项名是小写replicaof，不是REPLICAOF） - 如果主节点启用了密码认证，仅配
replicaof不够，必须同时加masterauth，否则日志里会反复出现MASTER aborted replication with an error: NOAUTH Authentication required
masterauth 配置被忽略的典型场景
很多人以为只要主节点设了 requirepass，从节点连过去自动带密码——其实完全不会。从节点必须显式声明 masterauth，且值要和主节点的 requirepass 完全一致。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 错误做法：只在主节点
redis.conf写requirepass redis123，从节点没配masterauth - 正确做法：从节点
redis.conf同时包含：replicaof 192.168.1.100 6379masterauth redis123 - 特别注意：如果主节点故障后被哨兵或手动提升为从节点，它自己也得配
masterauth——否则它再连新主节点时也会认证失败
replica-read-only yes 是默认行为，但别依赖它
从节点默认开启只读（replica-read-only yes），但这个设置只拦客户端直接发来的写命令，拦不住通过 Lua 脚本、EVAL 或管道批量发送的写操作。
- 一旦误开
replica-read-only no，从节点写入的数据不会同步回主节点，也不会传播给其他从节点，后续主从切换时极易导致数据覆盖或丢失 - 即使保持只读，也要禁用
CONFIG SET权限，防止运行时被动态关闭只读——生产环境建议用rename-command CONFIG ""彻底屏蔽 -
INFO replication输出中若看到role:slave但connected_slaves:0，先检查master_link_status，再确认是否因写操作触发了从节点自我保护性断连（某些旧版本有此行为）
复制中断后能否自动恢复？取决于 repl-backlog-size 和 repl-timeout
网络抖动导致断连后，Redis 默认尝试部分重同步（PSYNC），但前提是主节点的复制积压缓冲区（repl-backlog）还存着从节点断开时的偏移量。缓冲区太小或超时太短，就会退化成全量同步，拖慢恢复速度甚至压垮主节点。
-
repl-backlog-size 1mb是默认值，对中小流量够用；高写入场景建议调到 100mb 以上，避免频繁全量同步 -
repl-timeout 60控制连接空闲超时，默认 60 秒；若网络延迟大或心跳包被丢，可适当调大，但别超过 300（否则故障发现太慢） - 全量同步期间，主节点生成 RDB 会 fork 进程，内存占用翻倍；从节点加载 RDB 时阻塞所有请求——这两个窗口期都要纳入容量评估
真正容易被忽略的是：主从复制没有“最终一致性”保证，只有“最终可能一致”。异步复制下，从节点永远比主节点慢几毫秒到几秒，而这个延迟在监控里常常被当成“正常波动”放过。一旦业务依赖强一致性读（比如刚写完立刻查），就得绕过从节点，或者引入读己之写（read-your-writes）逻辑。这不是配置能解决的，是架构层面要提前想清楚的。
