Redis主从复制是异步机制，非强一致，仅保证最终一致性；主节点处理写请求并同步数据给多个只读从节点，通过全量+增量同步实现读写分离、数据冗余与故障恢复。
Redis 主从复制不是“强一致”的方案，而是一种以可用性和扩展性优先的异步同步机制。它能有效支撑读写分离、数据冗余和故障恢复，但必须正视其天然存在的数据延迟与最终一致性边界。
主从架构的基本构成与运行逻辑
主节点（Master）是唯一可写入口，所有 SET、DEL、HSET 等写命令都在此执行；从节点（Replica/Slave）默认只读，通过网络持续接收主节点的命令流并顺序重放。一个主节点可挂载多个从节点，但每个从节点只能归属一个主节点——这是由复制偏移量（replication offset）和运行 ID（run_id）共同约束的单向拓扑。
配置方式有三种：修改 redis.conf 中 replicaof <master-ip> <master-port>（永久生效）、启动时加 --replicaof 参数（单次有效）、运行中执行 REPLICAOF <ip> <port>（动态切换，重启失效）。断开则用 REPLICAOF NO ONE。
全量同步与增量同步如何协同工作
初次连接或复制状态丢失时触发全量同步：主节点执行 bgsave 生成 RDB 快照，同时将快照生成期间的新写命令缓存在复制积压缓冲区（repl-backlog）；RDB 文件传至从节点后加载，再回放缓冲区中的增量命令，完成初始对齐。
此后进入增量同步阶段：主节点每执行一条写命令，就将其写入 repl-backlog 并发送给所有在线从节点；从节点收到后立即执行，并更新自己的复制偏移量。该过程异步进行，不阻塞主节点请求处理。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- repl-backlog 是固定长度的环形缓冲区（默认 1MB），决定了断线重连后能否走部分重同步（partial resync）
- 若从节点断开时间过长，所需偏移量超出缓冲区范围，就会再次触发全量同步
- PSYNC2 协议优化了重连识别逻辑，支持复制 ID（replication ID）与偏移量双校验，显著降低误判全量同步的概率
数据一致性为何只能做到“最终一致”
主从复制默认采用异步复制：主节点写完即返回客户端成功，不等待从节点确认。这意味着在任意时刻，从节点的数据都可能滞后于主节点——尤其在网络抖动、大 key 写入或从节点负载过高时，延迟可达数百毫秒甚至更久。
这种设计换来的是高性能与高可用，但业务层需主动规避一致性风险：
- 写后立即读的场景（如下单后立刻查订单）不能路由到从节点，否则可能读不到最新数据
- 关键业务可通过 WAIT 命令要求主节点等待指定数量的从节点确认（最多阻塞 timeout 毫秒），实现有限度的强一致保障
- 监控 master_repl_offset 与各 slave_repl_offset 的差值，可量化延迟水位，用于告警或自动降级
主节点宕机时的一致性挑战
主节点宕机本身不会导致数据丢失（前提是开启了 AOF 或 RDB 持久化），但会引发两个关键问题：
- 脑裂（Split-Brain）风险：网络分区可能导致旧主节点短暂“复活”并继续接受写入，而哨兵已将新主选举完成，造成数据不一致
- 从节点数据陈旧：若宕机前最后一批写命令尚未同步到多数从节点，这些数据将永久丢失（除非使用 WAIT + 多副本确认）
因此，仅靠主从复制无法满足金融级强一致要求。需要结合哨兵（Sentinel）实现自动故障转移，或升级为 Redis Cluster 并启用 min-replicas-to-write 等参数增强写安全，再辅以应用层补偿机制（如幂等、对账）来兜底。
