一、开启复制
复制的数据流是单向的，只能由主节点复制到从节点，配置复制的方式有以下三种：
- 在从节点的配置文件中添加配置：slaveof ip port，随着Redis的启动而生效。
- 在从节点的启动命令redis-server后加入–slaveof ip port，进而生效。
- 直接在从节点的命令行中输入以下命令：slaveof ip port，从而生效。
总之呢，slaveof命令既可以在运行期动态配置，也可以提前在配置文件中配置。
查看关于复制的相关信息，使用如下命令：
info replication
默认情况下，从节点是只读的，通过以下配置设置，线上我们也建议如此，防止数据与主节点发生不一致。
slave-read-only yes
二、断开复制
使用如下命令：从节点断开复制后，并不会抛弃原有的数据。
slaveof no one
三、换主节点
如何换主节点呢，我们一样是执行如下命令：注意他会清空之前的节点的数据。
slaveof ip port
四、复制的安全性
复制的安全性，可以设置密码，在主节点的配置文件中加入：
requirepass password
为了能够让从节点与主节点正常通信，需要在从节点上记录主节点的密码：
masterauth password
五、关于复制延迟
- 网络因素，同机房的肯定延迟小，不同机房的延迟比较大，线上建议部署在统一机房。
- repl-disable-tcp-nodelay，
- 默认为关闭，主节点及时将数据发送给从节点，延迟会变小，但是会增加网络带宽的消耗，当在同一机房时建议配置。
- 如果这个参数设置为yes，主节点会合并较小的TCP数据包从而节省带宽，默认发送的时间间隔取决于Linux系统，一般默认为40秒，适用于跨机房部署的场景。
六、复制的拓扑结构
1、一主一从
当主节点命令并发量高且需要持久化时，可以只在从节点开启AOF，既保证了数据的安全性，又避免了持久化对主节点的性能干扰。
注意如果按照这样配置的话，主节点重启时会丢失数据，导致从节点也清空数据，这是因为主节点重启后，它的运行id变化，从节点认为自己换主了导致的，为了防止这种情况的发生，我们需要让从节点断开与主节点的连接，slaveof no one。
2、一主多从
可以将一些耗时的命令发到从节点来执行，防止慢查询对主节点造成阻塞。但是呢，这终结构，会导致主节点在面对多个节点的复制请求时，对性能的影响比较大。
3、树状主从
为了针对一主多从的缺点，有了树状主从的复制结构。
七、复制过程
如下图所示，复制的过程大致分为六步。
1、从节点保存主节点信息
从节点执行slaveof命令后，保存主节点的信息后，就直接返回。
2、从节点与主节点建立网络连接
从节点通过每秒执行的定时任务来维护复制的相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。如果连接失败，会继续连接。
3、发送ping命令
连接建立成功后，从节点发送ping请求进行首次通信，以检测主从之间的网络套接字是否可用，检测主节点当前是否可接受处理命令。
4、权限认证
验证从节点配置的密码，是否是与主节点一致的。
5、同步数据集
对于首次建立复制的场景，主节点会把所有的数据全部发送给从节点。
6、命令持续复制
当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续的把写命令发送给从节点，保证主从数据一致性。
八、部分复制
用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点，因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销。
部分复制是对老版复制的重大优化，有效避免了不必要的全量复制操作，psync命令既可以实现全量复制，也可以实现部分复制，psync命令是在Redis2.8版本以后才有的，所以尽量使用Redis2.8以上的版本。
部分复制需要以下三大组件的支持。
1、主从节点各自复制偏移量
参与复制的主从节点都会维护自身的复制偏移量。
主节点在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在info replication的master_repl_offset指标中。
从节点每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。
从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info replication中的slave_repl_offset指标中。
通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。计算出master_repl_offset-slave_offset字节量，根据这个差值判定当前复制的健康度。
2、主节点复制积压缓冲区
复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1M，当主节点响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区。
由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，由于部分复制和复制命令丢失的数据补救。其指标在info replication的repl_backlog开头的指标中。
3、主节点运行id
每个Redis节点启动后都会被动态的分配一个40位的十六进制字符串作为运行id，用来唯一识别Redis节点，从节点保存主节点的运行id识别自己正在复制的是哪个主节点。
因此如果Redis实例重启后运行id会发生改变，进而从节点以为换了主节点，会发生全量复制。
可以通过info server命令查看当前节点的运行id。
4、psync命令
psync {runid} {offset}：来完成全量复制和部分复制，runid就是从节点所复制主节点的运行id，offset是当前从节点已复制的数据偏移量。
如上图：
- 从节点发送命令给主节点。
- 主节点根据情况返回：
- +FULLRESYNC：从节点将触发全量复制流程（psync -1）。
- +CONTINUE：从节点将触发部分复制功能。
- -ERR：说明主节点版本低于2.8，无法识别psync命令。从节点将发送sync命令触发全量复制流程。
九、全量复制
如上图所示步骤进行全量复制的流程，以下几点值得注意的：
- 主节点bgsave时的日志，M开头的表示主节点日志，S从节点日志，C子进程日志。
- 如果RDB文件太大，传送时间已经超过了repl-timeout（默认60秒），会出现数据同步超时的错误，可以根据情况适当的调整参数repl-timeout。
- 为了保证主从数据的一致性，当主节点将RDB文件发送从节点后，主节点继续执行的写命令会记录到复制客户端缓冲区中，以便后续发送给从节点，进行增量同步。默认客户端复制缓冲区client-output-buffer-limit（默认slave 256M 64M 60）设置为60秒内缓冲区消耗持续大于64M或者直接超过256M，主节点将直接关闭复制客户端连接，造成全量同步失败。
- 从节点接收完主节点传送过来的数据后，会清空自身旧数据。
- 从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，它会立刻做bgrewrite操作。
十、心跳
如下图，主从节点建立复制后，他们之间维护着长连接并彼此发送心跳命令。
主节点每隔repl-ping-slave-period秒，默认为10秒，对从节点发送评命令。
从节点在主线程中每隔1秒发送replconf ack {offset}命令给主节点，上报自身当前的复制偏移量。
