1. 概述
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
2. 主从复制的相关操作
(1)配置文件:在从服务器的配置文件中加入 slaveof<masterip><masterport>。例如，新增redis6360.conf, 打开redis6360.conf并加入 slaveof 192.168.152.128 6359, 在6359启动完后再启6360，完成配置；
(2)启动命令：redis-server启动命令后加入 --slaveof<masterip><masterport>。例如，redis-server --slaveof 192.168.152.128 6359 临时生效
(3)查看状态：通过 info replication 命令可以看到复制的一些信息。
(4)断开主从复制：在slave节点，执行6380:>slaveof no one
(5)断开后再变成主从复制：6360:> slaveof 192.168.152.128 6359
(6)数据较重要的节点，主从复制时使用密码验证： requirepass
3. 主从复制原理
主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。
在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。
（1）保存主节点（master）信息
执行 slaveof 后 Redis 会打印如下日志：
（2）从节点与主节点建立网络连接
从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。
从节点与主节点建立网络连接。
从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：
如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。
关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：
（3）发送 ping 命令
连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：
检测主从之间网络套接字是否可用。
检测主节点当前是否可接受处理命令。
如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。
从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：
（4）权限验证
如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。
（5）同步数据集
主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。
（6）命令持续复制
当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。
4.数据同步原理
Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。
全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
- 从服务器配置主服务器的连接信息（slaveof属性）；
- 从服务器连接上主服务器，发送SYNC命令
- 主服务器判断是否为全量复制：如果是全量复制，则进入下一步；否则可以看增量复制的子流程。
- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
5.Redis主从复制的作用
（1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
（2）故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
（3）负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
（4）读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。
（5）高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
6.Redis主从复制的特点
（1）Redis的Replication的特点
a.同一个Master可以同步多个Slaves。
b.Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
c.Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave步期间，客户端仍然可以提交查询或修改请求。
d.Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。
e.为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。
f.Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。
g.支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
（2）Redis的Replication的缺点：
a.Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
b. 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
c. Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。
d. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
7.无磁盘复制原理
Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接通过网络发送给从数据库，避免了IO性能差问题。
启无磁盘复制：repl-diskless-sync yes
8.参考资料
http://www.zhuanzhi.ai/document/1e2a07d1b7d0c822d01039d808db2f1d
http://www.elecfans.com/d/883975.html
http://www.codedocs.net/blog/477
https://www.cnblogs.com/PatrickLiu/p/8426610.html
https://www.cnblogs.com/leeSmall/p/8398401.html
https://www.cnblogs.com/wdliu/p/9407179.html
https://www.cnblogs.com/kevingrace/p/5685332.html