Redis集群 主从复制

主从复制概述

---

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；
数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；

且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

如何使用主从复制

---

先学会用，才好去理解原理嘛

建立复制
主从复制的开启，完全是在从节点发起的；不需要我们在主节点做任何事

三种方式开启主从复制

配置文件：在从服务器的配置文件中加入：
slaveof [masterip] [masterport]
启动命令：redis-server启动命令后加入 –slaveof [masterip] [masterport]
客户端命令：Redis服务器启动后，直接通过客户端执行命令：
slaveof [masterip] [masterport]，则该Redis实例成为从节点。

1. 从节点查询一个不存在的key：
   
2. 在主节点中增加这个key:
   
3. 此时在从节点中再次查询这个key，会发现主节点的操作已经同步至从节点：
   
   删除亦然

主从复制的实现原理

---

三个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段

连接建立阶段

主要作用是在主从节点之间建立连接，为数据同步做好准备。

步骤1： 从节点保存主节点信息

从节点服务器内部维护了两个字段，即masterhost和masterport字段，用于存储主节点的ip和port信息。
需要注意的是，slaveof是异步命令，从节点完成主节点ip和port的保存后，向发送slaveof命令的客户端直接返回OK，实际的复制操作在这之后才开始进行。

步骤2： 建立socket连接(学习过网络编程会很好理解)

从节点每秒1次调用复制定时函数replicationCron()，如果发现了有主节点可以连接，便会根据主节点的ip和port，创建socket连接。如果连接成功，则：
从节点：为该socket建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收RDB文件、接收命令传播等。
主节点：接收到从节点的socket连接后（即accept之后），为该socket创建相应的客户端状态，并将从节点看做是连接到主节点的一个客户端，后面的步骤会以从节点向主节点发送命令请求的形式来进行。

步骤3：发送ping命令

从节点成为主节点的客户端之后，发送ping命令进行首次请求，目的是：检查socket连接是否可用，以及主节点当前是否能够处理请求。
从节点发送ping命令后，可能出现3种情况：

• 返回pong：说明socket连接正常，且主节点当前可以处理请求，复制过程继续。
• 超时：一定时间后从节点仍未收到主节点的回复，说明socket连接不可用，则从节点断开socket连接，并重连。
• 返回pong以外的结果：如果主节点返回其他结果，如正在处理超时运行的脚本，说明主节点当前无法处理命令，则从节点断开socket连接，并重连。

步骤4：身份验证

如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的，auth命令的参数即为配置文件中的masterauth的值。
如果主节点设置密码的状态，与从节点masterauth的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开socket连接，并重连。

步骤5：发送从节点端口信息

身份验证之后，从节点会向主节点发送其监听的端口号（前述例子中为6380），主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中；该端口信息除了在主节点中执行info Replication时显示以外，没有其他作用。

数据同步阶段

注意： Redis在复制进行期间也会尽可能的处理接收到的命令请求，但是，如果主从服务器之间的网络连接带宽不足，或者主服务器没有足够的内存来创建子进程和创建写命令的缓存区，那么Redis的运行效率必然受到影响。最好还是给主服务器留50%的内存

命令传播阶段

需要注意的是，命令传播是异步的过程，即主节点发送写命令后并不会等待从节点的回复；因此实际上主从节点之间很难保持实时的一致性，延迟在所难免。数据不一致的程度，与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的repl-disable-tcp-nodelay配置等有关。

repl-disable-tcp-nodelay no：该配置作用于命令传播阶段，控制主节点是否禁止与从节点的TCP_NODELAY；默认no，即不禁止TCP_NODELAY。当设置为yes时，TCP会对包进行合并从而减少带宽，但是发送的频率会降低，从节点数据延迟增加，一致性变差；具体发送频率与Linux内核的配置有关，默认配置为40ms。当设置为no时，TCP会立马将主节点的数据发送给从节点，带宽增加但延迟变小。

各场景下复制的选择及优化技巧

现在我们可以来总结一下，在下面常见的场景中，何时使用部分复制，以及需要注意哪些问题。

第一次建立复制

此时全量复制不可避免，但仍有几点需要注意：
如果主节点的数据量较大，应该尽量避开流量的高峰期，避免造成阻塞；
如果有多个从节点需要建立对主节点的复制，可以考虑将几个从节点错开，避免主节点带宽占用过大。
如果从节点过多，也可以调整主从复制的拓扑结构，由一主多从结构变为树状结构（中间的节点既是其主节点的从节点，也是其从节点的主节点）；
但使用树状结构应该谨慎：虽然主节点的直接从节点减少，降低了主节点的负担，但是多层从节点的延迟增大，数据一致性变差；且结构复杂，维护相当困难。

主节点重启

主节点重启可以分为两种情况来讨论，一种是故障导致宕机，另一种则是有计划的重启。

主节点宕机

主节点宕机重启后，runid会发生变化，因此不能进行部分复制，只能全量复制。
实际上在主节点宕机的情况下，应进行故障转移处理，将其中的一个从节点升级为主节点，其他从节点从新的主节点进行复制；且故障转移应尽量的自动化，后面文章将要介绍的哨兵便可以进行自动的故障转移。

从节点重启

从节点宕机重启后，其保存的主节点的runid会丢失，因此即使再次执行slaveof，也无法进行部分复制。

网络中断

如果主从节点之间出现网络问题，造成短时间内网络中断，可以分为多种情况讨论。
第一种情况：网络问题时间极为短暂，只造成了短暂的丢包，主从节点都没有判定超时（未触发repl-timeout）；此时只需要通过REPLCONF ACK来补充丢失的数据即可。
第二种情况：网络问题时间很长，主从节点判断超时（触发了repl-timeout），且丢失的数据过多，超过了复制积压缓冲区所能存储的范围；此时主从节点无法进行部分复制，只能进行全量复制。为了尽可能避免这种情况的发生，应该根据实际情况适当调整复制积压缓冲区的大小；此外及时发现并修复网络中断，也可以减少全量复制。
第三种情况：介于前述两种情况之间，主从节点判断超时，且丢失的数据仍然都在复制积压缓冲区中；此时主从节点可以进行部分复制。

复制相关的配置

与主从节点都有关的配置

首先介绍最特殊的配置，它决定了该节点是主节点还是从节点：
slaveof ：Redis启动时起作用；作用是建立复制关系，开启了该配置的Redis服务器在启动后成为从节点。该注释默认注释掉，即Redis服务器默认都是主节点。
repl-timeout 60：与各个阶段主从节点连接超时判断有关。

主节点相关配置

• repl-diskless-sync no：作用于全量复制阶段，控制主节点是否使用diskless复制（无盘复制）。所谓diskless复制，是指在全量复制时，主节点不再先把数据写入RDB文件，而是直接写入slave的socket中，整个过程中不涉及硬盘；diskless复制在磁盘IO很慢而网速很快时更有优势。需要注意的是，截至Redis3.0，diskless复制处于实验阶段，默认是关闭的。
• repl-diskless-sync-delay 5：该配置作用于全量复制阶段，当主节点使用diskless复制时，该配置决定主节点向从节点发送之前停顿的时间，单位是秒；只有当diskless复制打开时有效，默认5s。之所以设置停顿时间，是基于以下两个考虑：
  (1) 向slave的socket的传输一旦开始，新连接的slave只能等待当前数据传输结束，才能开始新的数据传输
  (2) 多个从节点有较大的概率在短时间内建立主从复制。
• client-output-buffer-limit slave 256MB 64MB 60：与全量复制阶段主节点的缓冲区大小有关，见前面的介绍。
• repl-disable-tcp-nodelay no：与命令传播阶段的延迟有关，见前面的介绍。
• masterauth ：与连接建立阶段的身份验证有关，见前面的介绍。
• repl-ping-slave-period 10：与命令传播阶段主从节点的超时判断有关，见前面的介绍。
• repl-backlog-size 1mb：复制积压缓冲区的大小，见前面的介绍。
• repl-backlog-ttl 3600：当主节点没有从节点时，复制积压缓冲区保留的时间，这样当断开的从节点重新连进来时，可以进行全量复制；默认3600s。如果设置为0，则永远不会释放复制积压缓冲区。
• min-slaves-to-write 3与min-slaves-max-lag 10：规定了主节点的最小从节点数目，及对应的最大延迟，见前面的介绍。
  从节点相关配置
• slave-serve-stale-data yes：与从节点数据陈旧时是否响应客户端命令有关，见前面的介绍。
• slave-read-only yes：从节点是否只读；默认是只读的。由于从节点开启写操作容易导致主从节点的数据不一致，因此该配置尽量不要修改。

总结

---

• 主从复制的作用：了解主从复制是为了解决什么样的问题，即数据冗余、故障恢复、读负载均衡等
• 主从复制的操作：即slaveof命令
• 主从复制的原理：主从复制包括了连接建立阶段、数据同步阶段、命令传播阶段
• 应用中的问题：包括读写分离的问题（数据不一致问题、数据过期问题、故障切换问题等）、复制超时问题、复制中断问题等
• 主从复制虽然解决或缓解了数据冗余、故障恢复、读负载均衡等问题，但其缺陷仍很明显：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制；这些问题的解决，需要哨兵和集群的帮助。