Redis数据同步到底是咋回事，原理和流程其实没那么复杂，但细节挺多的

说到Redis的数据同步，说白了就是让一个主Redis服务器（我们叫它“老大”）的数据，一模一样地复制到一个或多个从Redis服务器（我们叫它“小弟”）上去，这样做的目的很简单：一是为了备份，万一“老大”出问题了，“小弟”可以立刻顶上去，保证服务不中断；二是为了分担压力，“老大”主要负责写数据（比如用户下单、发微博），而“小弟”可以负责读数据（比如看商品信息、刷微博），读写分离,大家都不那么累。

这个同步的过程，核心思想其实不复杂，老大”把自己执行的每一个能改变数据的命令（比如set, lpush, hmset这些），都悄悄地记下来，然后原封不动地发送给所有“小弟”。“小弟”收到命令后，在自己身上再一模一样地执行一遍,这样两者的数据不就一样了吗？

就像你说的，细节挺多的，这个过程主要分为两大步：全量同步和增量同步。

第一步：全量同步——建立信任，交付家底

这通常发生在一个新的“小弟”刚来报到，或者“小弟”掉线太久的时候，想象一下，一个新员工入职，他需要先拿到公司至今所有的项目资料，才能开始和大家同步工作,Redis的全量同步就是这个意思。

1. 握手与注册：“小弟”启动后，会通过配置文件知道“老大”的地址，它主动向“老大”发送一个“同步请求”，说：“老大，我要跟你混，请把最新数据给我。”
2. 老大准备快照：“老大”收到请求后，不会停下手中的活，它会一边处理新的写命令，一边在后台默默地给自己当前的全部数据拍一个“快照”（Redis术语叫RDB文件）,这个快照就像是某个瞬间数据的完整照片。
3. 传送家当：快照拍好后，“老大”会把这个RDB文件发送给“小弟”。“小弟”会清空自己的旧数据（如果有的话），然后把这个RDB文件加载到内存里，到此为止，“小弟”的数据状态就和“老大”拍快照那个瞬间一模一样了。
4. 补上遗漏：在拍快照和传文件的这段时间里，“老大”可没闲着，它可能又处理了很多新的写命令，这些命令可不能丢。“老大”会用一个叫“复制缓冲区”（replication buffer）的地方,把这段时间内所有新的写命令都暂时存起来。
5. 最终同步：等“小弟”成功加载完RDB文件后，“老大”会把复制缓冲区里存的那些新命令再发给“小弟”。“小弟”一一执行这些命令后，它的数据就完全和“老大”实时同步了。

至此，全量同步完成。“小弟”正式上岗。

第二步：增量同步——持续跟进，保持同步

全量同步完成后，就进入了长期的、稳定的增量同步阶段，这时候，“小弟”的数据已经和“老大”齐平了，只需要持续跟进“老大”的新动作就行。

1. 命令传播：从此以后，“老大”每执行一个写命令，除了自己执行，还会把这个命令通过连接（称为复制链接）实时地发送给所有在线的“小弟”。
2. 小弟执行：“小弟”收到命令后，就像个忠实的复读机，原样执行这个命令,从而保证数据持续一致。

这个过程就像是一个领导在讲话,旁边的秘书在同步做记录一样。

那些关键的细节和问题

这里就开始体现“细节挺多的”了：

• 复制偏移量：“老大”和每个“小弟”都会各自维护一个“复制偏移量”，可以理解为命令流的字节计数器。“老大”每发送一个命令，它的偏移量就增加一点；“小弟”每接收并执行一个命令，它的偏移量也增加一点，通过对比这个偏移量，就能知道“小弟”是不是落后了,落后了多少。
• 复制积压缓冲区：这是另一个关键的缓冲区，它是一个固定大小的队列，存在于“老大”身上。“老大”不仅把命令发给“小弟”，还会在这个缓冲区里存一份最近发送的命令，如果某个“小弟”只是短暂地掉线了一会儿（比如网络抖动），又重新连上了，它只需要告诉“老大”自己最后的偏移量是多少。“老大”就会从这个缓冲区里找到断线之后的命令，发给“小弟”就行了，这样就避免了动不动就进行一次非常耗时的全量同步，这个缓冲区的大小很重要，设得太小,网络稍微不稳定就可能触发全量同步。
• 什么时候会触发全量同步？ 就是当“小弟”落后的数据太多，以至于“老大”的复制积压缓冲区里已经找不到它断线时的那个命令了（因为缓冲区是环形的，旧命令会被新命令覆盖），这时候就只能从头再来,进行一次全量同步。
• 同步是异步的：很重要的一点是，默认情况下，Redis的同步是异步的。“老大”把命令发给“小弟”后，不会等“小弟”执行完才响应客户端，而是立刻响应，这意味着在极端情况下，老大”刚响应完客户端就挂了，而这个命令还没传到“小弟”那里，数据可能会丢失（即使后来选了一个“小弟”当新“老大”），如果对数据一致性要求极高，可以配置为“同步等到至少一个‘小弟’确认收到”,但这会牺牲一些性能。

总结一下，Redis同步的原理就是“命令传播”，流程上先通过“全量同步”建立基础，再通过“增量同步”保持更新，而所有的细节，都是围绕着如何高效、可靠地完成这个传播过程，以及如何在网络不稳定或服务器故障时，智能地选择是“补课”还是“重读”来设计的。