Redis复制

Redis的主从复制策略是通过其持久化的rdb文件来实现的，其过程是先dump出rdb文件，将rdb文件全量传输给slave，然后再将dump后的操作实时同步到slave中

Redis复制流程概述
Redis的复制功能是完全建立在基于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生，那么首先要注意你的系统内存容量规划,Redis复制流程在Slave和Master端各自是一套状态机流转，涉及的状态信息是：

Slave 端：
REDIS_REPL_NONE

REDIS_REPL_CONNECT

REDIS_REPL_CONNECTED
Master端：
REDIS_REPL_WAIT_BGS***E_START

REDIS_REPL_WAIT_BGS***E_END

REDIS_REPL_SEND_BULK

REDIS_REPL_ONLINE
整个状态机流程过程如下：

1.Slave端在配置文件中添加了slaveof指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。

2.Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。

3.Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。

4.Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为REDIS_REPL_CONNECTED状态，Slave状态机流转完成。

5.Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为REDIS_REPL_ONLINE。
整个复制过程完成，流程如下图所示：



Redis复制机制的缺陷
从上面的流程可以看出，Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题。
比如一台线上正在运行的Master主库配置了一台从库进行简单读写分离，这时Slave由于网络或者其它原因与Master断开了连接，那么当Slave进行重新连接时，需要重新获取整个Master的内存快照，Slave所有数据跟着全部清除，然后重新建立整个内存表，一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力。
所以基于上述原因，如果你的Redis集群需要主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。