主从架构
什么是主从架构
Redis主从架构（Master-Slave Architecture）本质上是一种数据复制模子，它通过将数据从主节点复制到一个或多个从节点，实现数据冗余、负载分担和高可用性。
基本架构
- +-------------+
- | Master |
- | (写操作) |
- +------+------+
- |
- | 数据复制
- |
- +------v------+ +-------------+ +-------------+
- | Slave 1 |---->| Slave 2 |---->| Slave 3 |
- | (只读) | | (只读) | | (只读) |
- +-------------+ +-------------+ +-------------+
- 主节点(Master)：吸收写操作，执行数据变更
- 从节点(Slave)：从主节点复制数据，提供读服务
- 复制流：数据变更从主节点流向从节点
复制机制的工作原理
Redis主从复制履历了三代演进，分别是SYNC机制、PSYNC机制和PSYNC2机制，每一代都办理了前一代的关键问题：
1. 全量复制（Full Synchronization）
当从节点首次毗连主节点或复制出现问题必要重新同步时，会触发全量复制：
- +--------+ +--------+
- | Master | | Slave |
- +----+---+ +---+----+
- | |
- | PSYNC/SYNC |
- |<--------------------------|
- | |
- | FULLRESYNC |
- |------------------------->|
- | |
- | RDB文件传输 |
- |------------------------->|
- | |
- 从节点发送PSYNC/SYNC命令
- 主节点执行BGSAVE天生RDB文件
- 主节点将RDB文件发送给从节点
- 从节点清空自身数据，加载RDB文件
- 主节点将缓冲区中的写命令发送给从节点
- 开始一连复制过程
其主要缺点是网络中断后必须重新全量同步，对于大型数据集效率极低。
我曾在一个16GB的Redis实例上测试，全量同步必要约12分钟，期间体系负载增加300%。
2. 部分复制（Partial Synchronization）
部分复制,用于处置处罚短暂网络中断后的恢复：
- +--------+ +--------+
- | Master | | Slave |
- +----+---+ +---+----+
- | |
- | PSYNC <runid> <offset>
- |<--------------------------|
- | |
- | CONTINUE |
- |------------------------->|
- | |
- | 部分命令传输 |
- |------------------------->|
- | |
- 主节点维护一个复制积压缓冲区（replication backlog）
- 从节点断开重连后，发送PSYNC命令，包含主节点ID和复制偏移量
- 如果偏移量在积压缓冲区范围内，主节点复兴CONTINUE
- 然后主节点只发送从节点缺失的部分数据
这大大减少了短暂网络中断导致的全量同步，但在复杂拓扑结构下仍有范围。
3. PSYNC2机制（Redis 4.0+）
Redis 4.0引入的加强版部分复制，支持更机动的复制拓扑：
- +--------+ +--------+ +--------+
- | Master |---->| Slave1 |---->| Slave2 |
- +--------+ +--------+ +--------+
- 引入复制ID和复制历史记载，支持复杂拓扑下的部分复制
- 支持级联复制中任意节点断开后的部分同步
- 优化了复制协议效率，减少了约40%的网络传输
- 支持在主从切换等拓扑变更场景下的部分同步
之前测试全量同步,背面升级到PSYNC2后,主从切换时间从15分钟减少到了2分钟,很夸张的提升了.
这三代复制机制的演进体现了Redis在保持简朴性的同时不断提升复制效率和可靠性的计划哲学。"
主从架构的关键技术细节
1. 复制积压缓冲区（Replication Backlog）
- +---+---+---+---+---+---+---+---+
- | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... 命令序列
- +---+---+---+---+---+---+---+---+
- ^ ^
- | |
- tail head
- 环形缓冲区，默认大小1MB（可配置）
- 存储最近执行的写命令
- 用于支持部分复制
- 配置参数：repl-backlog-size
工作原理：
- 主节点将每个写命令同时写入复制积压缓冲区和从节点
- 缓冲区以偏移量(offset)标记每个命令的位置
- 从节点断开重连后，发送自身的复制偏移量
- 主节点检查该偏移量是否在缓冲区范围内：
- 如果在范围内，执行部分复制(CONTINUE)
- 如果不在范围内，执行全量复制(FULLRESYNC)
复制积压缓冲区的公道配置是Redis主从架构稳固性的关键因素之一，值得投入时间举行精细调优。
复制积压缓冲区大小应该至少能容纳从节点大概断开的最长时间内产生的所有写命令。计算公式为：
repl-backlog-size = 写入速率(bytes/s) × 预期最大断开时间(s) × 安全系数(1.5-2)
原本设置的1MB默认值导致频仍全量同步。通过监控发现：
- 平均写入速率：2MB/秒
- 网络偶发中断：最长90秒
计算得出抱负大小：2MB/s × 90s × 2 = 360MB
将参数调整为512MB后，全量同步次数从每天20-30次降至每月1-2次，体系稳固性显著提升。
2. 复制偏移量（Replication Offset）
- 主节点和从节点各自维护一个复制偏移量
- 体现复制的进度位置
- 用于检测复制是否一致
- 可通过INFO replication命令查看
3. 主节点ID（Run ID）
- 每个Redis实例启动时天生的40字节随机ID
- 用于标识复制关系中的主节点
- 从节点通过ID判断是否与之前毗连的是同一主节点
什么是PSYNC2
“PSYNC2是Redis 4.0引入的加强版部分复制机制，主要办理了复杂拓扑结构下的复制效率和稳固性问题。”
核心问题
“它主要办理了三个核心问题：
首先，办理了级联复制中的’多米诺骨牌’效应。在旧版本中，如果中间从节点断开重连，会导致整个复制链上的所有下游从节点都必要全量同步，消耗大量资源。
其次，优化了复制拓扑变更场景。以前主从切换后，从节点总是必要全量同步，纵然数据差别很小。
第三，提高了复制协议效率，改进了复制状态辨认机制，使复制过程更加稳固和高效。”
技术实现要点
" SYNC2通过几个关键技术实现这些改进：
- 引入了复制ID和复制历史记载，使从节点能够更正确地判断是否可以举行部分同步。
- 加强了复制状态跟踪机制，支持在复杂网络情况下的状态恢复。
- 优化了复制协议，减少了传输开销，提高了复制效率。"
实际价值
“在实际应用中，PSYNC2显著提高了Redis集群的稳固性和性能。例如，在我负责的一个项目中，主从切换时间从原来的15分钟减少到了不到2分钟，体系可用性得到了极大提升。”
总结
“总之，PSYNC2是Redis复制机制的紧张进步，为构建大规模、高可用的Redis集群提供了更结实的底子。”
PSYNC2机制的范围性
- 首先，它仍然依赖复制积压缓冲区，如果网络中断时间过长超出缓冲区容量，依然会触发全量同步。
- 其次维护复制历史记载必要额外内存资源，在资源受限情况中必要权衡。在极度情况下，如果主节点频仍切换，从节点大概必要频仍重建复制历史，这会增加主节点的负担。
主从模式有什么缺点
主要缺点有:
- 高可用问题:主从架构存在单点故障风险。主节点宕机会导致写服务完全不可用，且没有自动故障转移机制，必要人工干预
- 数据一致性问题:由于Redis采用异步复制机制，存在数据丢失风险。主节点崩溃时，已吸收但未同步到从节点的数据会永世丢失。
- 写性能问题:主节点写入压力大时，从节点大概出现延迟，影响读服务性能。
优点:
- 本钱低:使用平凡服务器即可搭建主从架构，本钱较低。
- 简朴易用:配置和管理相对简朴，得当中小规模应用。
- 读性能提升:主节点负责写入，从节点负责读取，可以显著提升读服务性能。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
