红色高性能Redis集群里主从同步那块儿到底咋整的，聊聊架构和细节

一个老大，多个帮手

这个集群里得有明确的分工,你提到的“主从同步”，关键就在“主”和“从”这两个角色上。

• 主节点（Master）：就是团队里的“老大”，也叫主库，所有写操作的指令，比如往数据库里塞新数据、修改数据、删除数据，都必须经过它，它是唯一能“动笔”的人，保证了数据来源的唯一性，不会乱套。
• 从节点（Slave）：帮手”，也叫从库，它的主要任务就是“抄作业”，从主节点那里把数据一模一样地复制过来，它自己一般不直接处理写请求（除非老大挂了，它有机会顶上去），主要负责处理读请求，帮老大分担压力。

这样一个“一主多从”的结构，好处很明显：读写分离了，写的压力主节点扛着，读的压力可以分散到多个从节点上，整个集群的性能和吞吐量就上去了，这就是“高性能”的一个重要基础。

同步的细节：怎么“抄作业”才能又快又准？

光有架构不行,关键是怎么同步，这个过程分为两个大阶段：全量同步和增量同步。

第一阶段：初次见面，全盘接手（全量同步）

当一个新帮手（从节点）刚加入团队，或者之前掉线太久，作业落下一大截，它就需要进行一次“全量同步”，这就像新员工入职，得把公司成立以来所有的规章制度、项目资料全部学习一遍。

这个过程是这样的：

1. 打招呼认老大：从节点启动后，会发送一个命令给主节点，说：“老大，我是新来的，我要跟你混。”
2. 老大准备资料：主节点收到请求后，不会立刻把现在的数据给它，而是先把自己当前的数据状态拍一个“快照”（RDB文件），这个快照就像是公司某个时间点的完整备份。
3. 边传资料边记新事：在主节点吭哧吭哧生成快照的同时，新的写操作还在源源不断地进来，主节点会把这些新的写命令记录在一个“工作日志”（Replication Buffer，复制缓冲区）里，免得漏掉。
4. 发送资料：快照生成好了，主节点就把这个RDB文件发送给从节点。
5. 从节点清空学习：从节点收到RDB文件后，会先清空自己原来的旧数据（确保干净），然后把这个快照数据全部加载到自己的内存里，这样一来，它的数据状态就和主节点拍快照的那个时刻一模一样了。
6. 补上遗漏：快照数据加载完后，主节点会把刚才记录在“工作日志”里的那些新的写命令，再发送给从节点，从节点执行这些命令，把自己的数据更新到最新，至此，全量同步完成，从节点和主节点数据完全一致。

第二阶段：日常跟进，查漏补缺（增量同步）

全量同步是个重体力活,非常耗资源（CPU、内存、网络带宽），一旦从节点和主节点同步上了，之后就要用“增量同步”来保持更新，这就像老员工每天只需要看工作群里的新通知就行了，不用再把公司历史读一遍。

增量同步的核心就是那个“工作日志”（Replication Buffer），主节点之后收到的每一个写命令，除了自己执行，还会往这个缓冲区里追加一份，每个命令都有一个偏移量（offset），可以理解为在日志里的位置编号。

从节点会持续地从主节点拉取这个缓冲区里自己还没同步的命令（通过对比自己和主节点的偏移量就知道差多少了），然后在自己本地执行这些命令，这样就实现了数据的实时（或近实时）同步。

可能遇到的问题和解决办法

这个机制听起来不错,但也会遇到问题，最常见的就是网络闪断。

假设从节点和主节点之间的网络抖动了一下,断了几秒钟又连上了，这时候从节点落后的数据量不大，可能就几十个命令，它需要的命令还在主节点的“工作日志”缓冲区里，从节点只需要把自己的偏移量发给主节点，主节点一看，“哦，你才到100号命令，我现在都150号了，我把101到150的命令发给你。”这就是增量同步，很快就能恢复。

如果网络中断时间太长,主节点接收的写命令非常多，多到把“工作日志”缓冲区都挤满了（缓冲区有固定大小，是个环形结构，新命令会覆盖旧命令），那么从节点断线期间错过的那些旧命令就被永久覆盖了，这时候，从节点再连上来，发现自己需要的起始命令已经在缓冲区里找不到了，增量同步就没办法进行了，那怎么办？只能从头再来，触发一次代价高昂的全量同步。

这个“工作日志”缓冲区的大小配置就很关键，设得太大浪费内存，设得太小又容易在网络不稳定时导致全量同步，需要根据业务流量和网络状况做个权衡。

总结一下

红色高性能Redis集群的主从同步,说白了就是一个“老大”带“帮手”的模式，新手入职或掉队太远就搞一次“全盘学习”（全量同步），平时就靠“看工作群通知”（增量同步）来保持同步，这个机制在保证数据一致性的前提下，尽可能地提升效率，是实现集群高可用和高性能的基石，一旦主节点出事，数据最全的那个从节点就能被推选为新老大，继续提供服务。