流浪小鱼1. Redis高可用架构设计原理
Redis作为内存数据库的标杆产品，其高可用设计经历了从主从复制到哨兵模式，再到集群方案的演进过程。主从复制架构中，从节点通过全量同步（RDB文件传输）和增量同步（命令传播）两种方式保持数据一致性。当主节点挂掉时，需要人工介入进行故障转移，这显然无法满足现代分布式系统对高可用的要求。
哨兵模式通过引入Sentinel进程集群，实现了自动化的故障检测与转移。每个Sentinel节点会定期向主从节点发送PING命令检测存活状态，当超过quorum数量的Sentinel判定主节点不可达时，会触发故障转移流程。这个过程中涉及主观下线和客观下线两种状态判断，以及领导者Sentinel选举等关键机制。
实际生产环境中建议至少部署3个Sentinel节点，且分布在不同的物理机上。我曾遇到过因两台服务器同时掉电导致双Sentinel节点无法达成共识的情况，这个教训说明奇数节点和物理隔离的重要性。
Redis Cluster采用去中心化的分片架构，数据按哈希槽（16384个slot）划分到不同主节点上。每个节点保存完整的集群拓扑信息，客户端可以请求重定向到正确的节点。节点间通过Gossip协议传播状态信息，故障检测依靠PING/PONG消息超时机制，故障转移则采用类似Raft的领导者选举算法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据同步机制深度剖析
2.1 全量同步流程
当新从节点加入或主从复制中断时间过长时，会触发全量同步：
- 从节点发送PSYNC ? -1命令请求全量同步
- 主节点执行BGSAVE生成RDB文件，期间新写入命令存入复制缓冲区
- RDB文件传输完成后，主节点发送缓冲区积压的命令
- 从节点清空旧数据，加载RDB文件后执行缓冲命令
这个过程中有几个关键参数需要关注：
- client-output-buffer-limit：防止复制缓冲区耗尽内存
- repl-timeout：同步超时时间（默认60秒）
- repl-backlog-size：环形复制积压缓冲区大小（默认1MB）
2.2 增量同步优化
在断线重连场景下，如果从节点的偏移量仍在主节点的复制积压缓冲区范围内，就可以只同步缺失的部分命令。我们通过调整repl-backlog-size（建议设为平均网络中断时长的2倍写入量）和repl-