Redis主从复制的核心是通过异步复制方式，主节点将写操作的命令异步发送给从节点，从节点接收并执行这些命令来实现数据同步。但数据同步延迟问题主要源于网络抖动、从节点负载高等因素。为解决延迟，可启用wait命令等待指定从节点完成指定数量的复制偏移量同步，或使用min-replicas-to-write和min-replicas-max-lag配置，主节点在满足从节点数量和最大延迟要求时才允许写操作。哨兵机制通过监控主从节点，自动故障转移实现高可用，当主节点故障时，哨兵选举从节点为新主，并通知客户端更新连接，确保服务不中断。

主从复制原理图解

主从复制分为全量同步和增量同步。全量同步时，主节点执行bgsave生成RDB文件，从节点通过repl-diskless-sync开启无磁盘同步，主直接将RDB发送给从。从节点加载RDB后发送fullresync请求，主节点记录从节点的复制偏移量和repl_id，以后通过repl_backlog_buffer增量发送命令，实现低延迟同步。图示：主节点fork子进程生成RDB → 发送给从节点 → 从节点加载并回执 → 后续命令增量复制。

数据同步延迟解决方案

数据同步延迟痛点：从节点落后主节点repl_backlog导致读数据陈旧。为解决，可监控info replication中的behind_master字节差值；使用redis-check-aof --fix修复AOF日志；配置repl-diskless-sync delay 5秒内无全同步需求时直接内存发送RDB；主节点repl-backlog-size 1GB确保backlog足够大，避免从节点重连全同步；客户端读时使用READONLY从节点，但结合wait 1 1000等待1个从节点同步1000字节，保障强一致性读。

哨兵机制高可用部署图解

哨兵（Sentinel）至少3个节点组成仲裁，监控主从心跳，主节点每秒发送PING，从节点10秒is-master-down后客观下线（2个哨兵同意）。选举流程：哨兵优先级（slave-priority）、偏移量最近、运行ID小的从节点升主。图示：哨兵集群 → 检测主故障 → 客观下线 → 选举新主 → 从节点复制新主 → 通知客户端。sentinel monitor mymaster 127.0.0.1 6379 2 配置示例。

实际配置解决痛点案例

在高并发场景，主从延迟达秒级，使用parallel-syncs 4从节点并行全同步；部署3哨兵，sentinel failover-timeout 60000；客户端连接pool中维护哨兵发现主节点地址动态切换。监控lag通过pubsub模式哨兵发布__sentinel__:hello频道心跳，延迟超阈值告警。实际图解：主6379 从6380/6381 哨兵26379/26380/26381，故障时自动切换读写分离流量无感知。

优化高可用架构图

结合主从+哨兵，解决单点故障：多DC部署，从DC1主复制DC2从+哨兵；使用CRDB（Redis Cluster）扩展但哨兵专注HA。延迟优化脚本：while true; do redis-cli -h master info replication | grep behind_master; sleep 1; done 监控。图示完整架构：客户端 → 哨兵发现主 → 主写从读 → 故障转移链路。

FAQ

Q: 主从复制延迟如何实时监控？
A: 使用INFO replication命令查看behind_master字段，或Prometheus+Grafana采集指标，设置告警阈值。

Q: 哨兵选举新主需要满足什么条件？
A: 从节点slave-priority最低（配置0禁用）、复制偏移最近、runid字典序最小，至少quorum个哨兵同意。

Q: 如何避免脑裂？
A: 哨兵客观下线需多数同意，down-after-milliseconds 30000ms，failover-timeout确保切换原子性。

Q: 读写分离时强一致性怎么保证？
A: 写后调用WAIT master 1 100等待从节点同步指定偏移，避免读旧数据。