Redis是大型架构核心，下面我详解Redis主从复制@mikechen
Redis主从复制
Redis 的主从复制（Master-Slave Replication），是 Redis 高可用架构的基石。
无论是哨兵（Sentinel）模式还是集群（Cluster）模式，底层都依赖主从复制来保证数据的一致性和冗余。
简单来说，主从复制实现了：数据备份、读写分离、压力分摊。
Redis主从复制原理
Redis 采用基于主从（master-slave，现多称为 primary-replica）的复制模型。
主节点负责写操作与数据变更，若干从节点异步接收并应用主节点的写命令。
复制流程可分为初次同步（full sync）与增量同步（partial sync）：
初次同步：当从节点与主节点建立连接且无可用复制偏移或复制缓冲断档时。
主节点生成 RDB 快照并将其发送给从节点，从节点载入快照后接收主节点发送的持续命令流完成状态同步。
增量同步：主节点维护复制积压缓冲区（replication backlog）。
若连接短暂断开且断点仍在积压缓冲区内，从节点可以基于复制偏移仅接收缺失命令，无需全量重同步，减少带宽与时延。
复制是默认异步的：主节点在返回写命令成功后即刻响应客户端。
并不会等待所有从节点确认，因此存在主从数据短暂不一致的窗口。
为提高数据安全性，可启用半同步或使用 Redis Sentinel、Redis Cluster 等机制实现更复杂的一致性与高可用策略。
案例
场景：主库宕机自动切换。
架构：1 主 2 从 + 3 哨兵 + RDB/AOF 持久化。
实施：哨兵 conf：sentinel monitor mymaster 127.0.0.1 6379 2。
主挂后，哨兵选举从库为主，通知客户端（sentinel get-master-addr-by-name）。
原主恢复后，自动变从。
效果：切换时间<30s，数据丢失<1s 命令。
痛点&解决：选举脑裂 → 用 quorum=2 + down-after-milliseconds=5000 调优。
