为什么要主从复制：
如果使用redis 的时候只使用一个数据库服务，那是不存在什么主从复制的。当redis 服务在两个以上时才会有主从复制。为了读写分离和减轻压力，在实际生产中一般会用到多个redis 服务。多个服务那就存在数据同步的问题，主从复制就是解决redis 数据同步的问题。
主从复制如何实现：
从master 复制数据到 slave 有两种复制方式，一种是全量复制，一种是部分复制。
全量复制：主节点数据一次性全部发送给从节点。首先这种方式发送的数据量大，耗费时间和空间是肯定的。
部分复制：主节点数据可以有选择地发送给从节点。像在发送过程中出现网络闪断的情况下，原先已将部分数据发送给从节点了，那么在网络连通好之后再将另外部分发送给从节点。
数据同点命令：psync(老版本是sync 不支持部分复制)
psync 命令相关机制：
1.主从节点各自复制偏移量；
2.主节点复制积压缓冲区；
3.主节点运行ID；
4.复制偏移量；
5.参与复制的主从节点都会维护自身复制偏移量；
psync {ID} {offset}
ID:主节点运行ID ，无则为？
offset:当前从节点已复制的数据的偏移量 ，-1表示第一次复制
主节点运行ID：该ID是40位十六进制字符，它的作用是唯一识别redis 节点。该ID是动态分配的，所以它是完全随机的，在服务重启或变更整体数据集后原ID将被替换。可以用 info server 命令查看当前节点的运行ID。
在主节点收到从节点的psync命令后，将会回复：
1.+FULLRESYNC {runID} {offset} 全量复制；
2.+continue 部分复制 ；
3.+ERR 无法识别命令，版本低于2.8，得用sync;
主从复制步骤：
1.从节点第一次复制时肯定是全量复制，因为并不知道主服务的ID，所以执行psync ? -1 命令；
2.主节点收到命令，分析出为全量复制，返回 +FULLRESYNC {runID} {offset}；
3.从节点接收到响应，保存运行ID，下次发送请求时就可以把ID给写上了；
4.主节点执行bgsave ，保存RDB文件到本地；
5.主节点将RDB文件发送给从节点，从节点接收到文件后，直接将其作为数据文件。该过程涉及文件传输，耗时并且受网络的影响。
redis 的默认复制时间rel-timeout为60秒，超时则复制失败。
在传输RDB文件时，主节点是可以进行写操作的，此时就会有新产生的数据，那么这个数据从节点按理说也是应该行到的，但RDB文件已生成正在传输，不能再修改了，怎么办呢。实际上此时的操作命令会保存在复制积压缓冲区中。在从节点加载完RDB文件后，主节点再把缓冲区内的数据发给从节点。
积压缓冲区默认只有1M，如果在RDB文件传输的这60秒过程中，写的数据超过1M，那是会发生缓冲区溢出的。所以在传输RDB的时候写的量是不能太大的。
6.在接收完RDB文件后，从节点将清空自身的旧数据：flush old data ，然后加载RDB文件，该加载操作也是个耗时操作。此时从节点的读操作还是可以继续的，那么就有可能发生这些情况：读到旧的也就是过期的数据、或是刚好数据清空了读到错误数据。这个是可以不让它读的：slave-server-stale-data 参数设置开关可读，默认是开的。
无盘复制：
一般的主从复制，主节点是先将RDB文件保存到本地的磁盘中，再发送给从节点。无盘复制的意思就是，不保存在本地的磁盘中，而是直接发送给从节点。这种情况对网络的要求是比较高的。主要用在机器磁盘情能较差但是网络带宽充裕的情况下。