Redis全量同步和增量同步原理

数据库小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Redis全量同步和增量同步原理》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

全量同步

主从第一次同步是全量同步：也就是说，当你主从节点连接建立后，需要执行一次全量同步。那么Redis如何实现全量同步呢？

其实本质就是Master 给 slave 发送其保存的RDB文件。slave读取RDB文件恢复数据

 详细介绍：

【第一步】slave与master建立连接后，master判断该slave 是否是第一次建立连接。那么该如何判断呢？

其实Master和slave都有一个Replication Id，简称replid，若id一致说明是已经建立过连接了，不需要进行全量同步，则需要进行增量同步。

【第二步】master 执行bgsave，生成RDB文件，同时在生成RDB的同时，也会产生一个baklog文件记录RDB期间的命令，然后将RDB文件发送给从节点，从节点加载RDB文件中的数据。至此全量同步已经完成。

【第三步】也就是后续master和slave在进行同步时候就是增量同步。则需要利用之前生成的baklog文件。

【总结全量同步】

• slave节点先进行增量同步；
• master节点判断replid，发现不一致，拒绝增量同步；
• master将完整内存数据生成RDB，发送RDB到slave；
• slave清空本地数据， 加载master的RDB；
• master将RDB期间的命令记录在repl_baklog，并持续将lgo知道命令发送给slave；
• slave执行接收到的命令，保持与master之间的同步。

增量同步

主从第一次同步是全量同步，但如果slave重启后同步，此时slave重启后，slave节点和master节点的数据之间有落后，因此需要进行增量同步。

【过程】

master节点和slave节点中维护了一个环形数组（前文提到的repl_baklog）和一个指针为offset。

slave来申请增量同步，带着replid和offset，然后master根据获取offset之后的数据，将其发送给slave，slave进行同步。

• 此时会出现一个问题，当slave下限太久时，master中存储的数据已经超过了这个repl_baklog的上线，因此就需要重新进行全量同步。

通过对Redis主从集群的同步介绍，可以从以下几个方面来优化Redis的主从集群

• 在master中配置repl-diskless-sync yes 启用无磁盘负责，来避免全量同步时的磁盘IO。（应用场景：你的磁盘传输比较慢，但是你的网络带宽很大，网络状况极好。）
• Redis单节点上内存占用不要太大。减少RDB文件的大小。
• 适当的提高repl_baklog的大小，尽量slave恢复后做全量同步。
• 限制一个master上的slave节点数量，可以采用主从链的形式。

总结

理论要掌握，实操不能落！以上关于《Redis全量同步和增量同步原理》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！