在高并发做事当中，如果利用单个Redis实例，由于Redis采取单进程单线程处理所有要求的办法，即每次只有一个要求在处理，后面的要求排队，如果前面要求实行韶光长了，则会影响后面所有要求。以是可以拓展到多个Redis实例，采取主从机制，一个master和多个slave，master和多个slave包含相同的数据，master卖力处理写要求，slave卖力读要求。Redis主从同步即是实现这种机制的，master处理完写要求后，同步给多个slave，从而担保数据的终极同等性。
二、同步架构
Redis的主从同步支持两种机制，一种为master同步给所有slave，其余一种slave级联同步，即master同步给一个slave，这个slave再充当伪“master”同步给下一个slave，这种机制的好处是减少master的数据传输量，节省master的带宽，同时在新slave加入时或者多个slave重连时，避免全部须要master来吸收，造成master资源紧张，如fork子进程实行BGSAVE。详细架构如图：
配置某个redis利用其余一个redis作为master也很大略，redis.conf的配置如图：同时slave默认也是只读的，但是可以吸收并实行master同步过来的写命令进行数据修正，保持与master同等。
三、全量同步
发生情景：从做事看重启或者Redis2.8之前版本的断线重连都会进行全量同步。
全量同步：slave启动或者slave断开重连master的时候，slave会发生SYNC命令给master，master吸收到该命令后，则会通过bgsave启动一个子进程将当前韶光点的master全部数据的快照写到一个文件中，然后发送给slave。slave吸收到之后则清空内存，载入这些数据。详细过程如下：
1. slave发生SYNC命令给master，要求实行全量同步，然后slave在等待期间，根据配置（如下）可以利用旧数据相应客户端要求或者直接报错；
2. master吸收到SYNC要求后，通过BGSAVE启动一个子进程将当前数据快照写到一个快照文件；同时主进程采取一个缓冲区保存这段韶光内的所有写要求；把稳如果同时有多个slave发送SYNC给master，master只会实行一次BGSAVE，然后将快照文件发送给这些slaves；
3. 子进程完成快照文件的写入，向slave发送这个快照文件（正常逻辑来说是子进程发送待查看源代码确认）；主进程连续采取缓冲区缓存写命令；slave吸收到快照文件后，删除旧数据，载入新的快照数据，此期间会壅塞客户真个要求；
4. 子进程发送快照文件完毕后，主进程将缓冲区的数据以Redis命令协议形式，如DEL、SET，发送给slave。slave载入完快照数据后，则可以开始处理客户真个要求了。同时slave吸收master发送过来的缓冲区的写命令并实行；
5. 此后进入增量同步（命令传播）模式，不断吸收master的写要求，实现终极同等性。
详细过程如图所示：
四、增量同步（命令传播）
增量同步即为master每吸收并实行一个写命令都同步给所有的slave，slave吸收到该写命令后实行对自身数据的修正从而保持与master的数据同等。
五、部分同步：PSYNC
在Redis2.8+版本，Redis的slave在与master断开连接重连的时候，默认是利用新的PSYNC同步方法，而不是原来的SYNC，由于断线重连时，slave是包含有数据的，只是可能掉队于master，以是没必要又进行一次全量同步。PSYNC的实现详细为：
命令格式：
PSYNC <runid> <offset>runid:主理事器IDoffset:从做事器末了吸收命令的偏移量
1. run_id：master的id，表面master身份，slave利用该slave来记住自己目前是同步哪个master；如果slave没有保存，则发送PSYNC ? -1，实行全量同步；数值为40位的十六进制字符串，Redis重启后会改变，从而担保重启后，slave利用全量复制，担保数据安全性。
2. replication offset：即当前实行主从同步到哪里了，master掩护自身当前同步了多少给slaves，即发送了N个字节给slave，则会实行offset+N；slave掩护自身当前从master同步了多少，常日slave的小于或即是master的；
3. 复制积压缓冲区：即master已同步写命令缓存列表，master以FIFO的办法保存最近同步给slave的数据，列表大小一定，以是如果slave重连时，slave的replication offset月master的replication offset的差值大于该列表大小，则解释slave丢失的部分数据（写命令）不能从该列表获取了，此时须要实行全量同步，否则master将这个差值对应列表中的数据发送给slave，slave只需实行这些写命令即可。
六、CAP理论
CAP理论为：在分布式系统中，多个节点之间只能知足CP或AP，即强同等性和高可用是不能同时知足的。Redis的主从同步是AP的，详细对高可用的强度哀求，可用通过在redis.conf配置，即有至少有多少个slaves存在和至多多少秒内没相应，则才实行写要求，否则报错，配置与解释如图：默认为关闭这个特性，即master始终吸收客户端写要求。
