什么是主从复制

我们正常在项目中对redis进行应用，一般都不会是单点的。因为，单点的宕机即不可用，不能保证可用性。另外，单点redis读写指令都会打到同一个服务里面，也会影响性能。在通常的应用中，对redis的读操作远远多于写操作，所以，我们一般会选择“一主多从”的集群策略。

• 主中的数据有两个副本（replication）即从redis1和从redis2，即使一台服务器宕机其它两台服务也可以继续提供服务。
• 主中的数据和从上的数据保持实时同步，当主写入数据时通过主从复制机制会复制到两个从服务上。
• 只有一个主redis，可以有多个从 redis。
• 主从复制不会阻塞master，在同步数据时，master可以继续处理client请求。

一个可以即是主又是从，如下图：

主从复制过程

一般当slave第一次启动连接master，或者“被认为是第一次连接”，是主从采用全量复制。全量复制的执行流程如下：

1. slave redis启动. 会从redis.conf中读取master ip和host。
2. 定时任务每秒检查是否有新的mater需要连接，如果发现就与master建立socket连接。
3. slave发送ping指令到mater。
4. 如果mater配置require pass，slave需要发送认证给master。
5. Salve会发送sync命令到Master。
6. Master启动一个后台进程，将Redis中的数据快照rdb保存到文件中。
7. 启动后台进程的同时，Master会将保存数据快照期间接收到的写命令缓存起来。
8. Master完成写文件操作后，将rdb发送给Salve。
9. Salve将rdb保存到磁盘上，然后加载rdb到redis内存中。
10. 当Salve完成数据快照的恢复后，aster将这期间收集的写命令发送给Salve端。
11. 后续Master收集到的写命令都会通过之前建立的连接. 增量发送给salve端。

调用流程图如下：

增量复制

当slave节点与master全量同步后，master节点上数据再次发生更新，就会触发增量复制。

当我们在 master 服务器增减数据的时候，就会触发 replicationFeedSalves()函数，接下来在 Master 服务器上调用的每一个命令都会使用replicationFeedSlaves() 函数来同步到Slave服务器。当然，在执行此函数之前master服务器会判断用户执行的命令是否有数据更新，如果有数据更新并且slave服务器不为空，才会执行此函数，函数主要的工作就是把用户执行的命令发送到所有的 slave服务器，让slave服务器执行。

流程如下图：

断点续传（continue replication）

断点续传或者说是断点恢复复制，也就是说 slave 因为某种原因与master断开连接了一段时间，然后又与master发生重连。redis2.8以后对于这种场景进行了优化，开始加入了PSYNC同步策略。这种策略性能一定是大于全量复制的。

1. 从服务器向主服务器发送PSYNC命令，携带主服务器的runid和复制偏移量；
2. 主服务器验证runid和自身runid是否一致，如不一致，则进行全量复制；
3. 主服务器验证复制偏移量是否在积压缓冲区内，如不在，则进行全量复制；
4. 如都验证通过，则主服务器将保持在积压区内的偏移量后的所有数据发送给从服务器，主从服务器再次回到一致状态。

PSYNC 核心参数

介绍一下，断点续传的几个核心参数，offset、backlog、runid。这三个参数在 PSYNC 中起到了至关重要的作用，下面我们来一一介绍一下。

• offet复制偏移量 , offset是用来记录master和lslave某个时段的数据版本状态的，slave每秒会向master上报offset，master保存下来，当触发 PSYNC 时再拿来和master的offset数据作对比。说白了，它就是记录数据在某一时刻的快照，用来对比 master 和 slave 数据差异用的。
• backlog积压缓冲区

1. 这个也是一个非常核心的参数，它默认大小为1mb，复制积压缓冲区是由Master维护的一个固定长度的FIFO队列，它的作用是缓存已经传播出去的命令。当Master进行命令传播时，不仅将命令发送给所有Slave，还会将命令写入到复制积压缓冲区里面。
2. 全量复制的时候，master的数据更新（读写操作，主动过期删除等）会临时存放在backlog中待全量复制完成后增量发到slave，必须为此保留足够的空间。
3. 断点续传时，backlog会存下slave断开连接后，master变更的数据。当然由于它大小有限制，而且先进先出特性，所以达到缓冲大小后会弹出老数据。这样，就可以把它作为一个衡量执行sync还是psync的一个标准（backlog = offset : 部分同步，backlog < offset 执行全量同步）。一般为了避免，大规模全量复制，我们都会给一个恰当的值，根据公式second*write_size_per_second来估算：其中second为从服务器断线后重新连接上主服务器所需的平均时间（以秒计算）；而write_size_per_second则是主服务器平均每秒产生的写命令数据量（协议格式的写命令的长度总和）；

• master run id, master唯一标示，slave连接master时会传runid，master每次重启runid都发生变化，当slave发现master的runid变化时都会触发全量复制流程。

优缺点

优点：

1. 高可靠性：一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行；另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题；
2. 读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。

缺点：

1. 故障恢复复杂，如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其它从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐；
2. 主库的写能力受到单机的限制，可以考虑分片；
3. 主库的存储能力受到单机的限制，可以考虑Pika；
4. 原生复制的弊端在早期的版本中也会比较突出，如：Redis复制中断后，Slave会发起psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿；又由于COW机制，导致极端情况下的主库内存溢出，程序异常退出或宕机；主库节点生成备份文件导致服务器磁盘IO和CPU（压缩）资源消耗；发送数GB大小的备份文件导致服务器出口带宽暴增，阻塞请求，建议升级到最新版本。

分享自：https://www.jianshu.com/p/5de2ab291696