在redis中，为了保证redis的高可用性，一般构建主从模式这一集群模式。
主从模式可以保证redis的高可用性。 那么，redis如何保证主从服务器的数据完整性？ 下面介绍redis主(master )从(slave )同步的原理
全量同步
复制id :每个redis master实例在启动时生成随机id以标记此实例。 第一次同步时，从节点不知道这个id，要使用吗？ 相反，
offest表示复制进度(kafka )，第一次同步用-1表示
主库在同步数据时不会被阻止，为了确保数据的完整性，RDB生成后的操作命令被写入复制缓冲器后，发送到从节点，从节点保证数据的完整性
如上所述，主从同步主要需要时间来生成和发送RDB文件。 如果从节点数量较大，则主节点将忙于fork子进程生成RDB文件并进行全局同步，从而阻止主进程并降低性能。
为了解决这个问题，我们使用了主-从-从的体系结构，并在从-从之间建立了主从同步
基于长连接的命令传播
当主从库完成完整复制时，它们之间将保持直接连接，主库将通过此连接将后续的相继接收的命令操作重新同步到从库
但是，如果连接断开，主从库将以增量副本的形式继续同步，但如果slave节点找不到存储的复制id，则会进行完全同步
增量同步
当主从库断开连接时，主库会将断开连接时收到的写入命令写入复制缓冲器，同时这些操作也会写入名为repl_backlog_buer的缓冲区。
复制缓冲区由客户端-输出-缓冲区-极限速度参数设置。 如果此值太小，连接将断开，并导致以下问题：
1 )当master-slave复制连接断开时，服务器端释放与连接相关的数据结构。 复制缓冲区中的数据也将丢失，并在主机和从机之间重新启动复制。
2 )还有更严重的问题。 主从机的复制连接断开，主从机的rdb bgsave和rdb重发操作进入无限循环。
client-output-buffer-limitclasshardlimitsoftlimitsoftsecondsclass 3360客户端类型。 包括常规、Slaves、Pub/SubNormal:常规客户端。 缺省limit为0，即没有限制。 Pub/Sub:公开订阅的客户端的。 默认hard limit 32M，soft limit 8M/60s。 Slaves:来自库中的复制客户端。 默认的hard limit 256M是soft limit 64M/60s #redis默认配置：客户端- output-buffer-limit normal 0客户端- output-buffer-- output
增量同步通过repl_backlog_buer实现，repl_backlog_buer为增量同步原理：，主库位于写入位置(master _ repl _ oor
主从连接恢复后，从库向主库发送psync命令，将自己的slave_repl_oset发送到主库，主库收到slave_repl_oset命令后
参数repl_backlog_size控制repl_backlog_buer的大小