3.Redis主从复制的一些概念

主要事项

• 如果没有设置密码需要关闭保护模式才能被外部访问，如果Redis设置了密码(requirepass)则不需要修改保护模式
  protected-mode no

主从复制的作用

• 数据冗余、故障恢复：
  主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
• 读写分离、负载均衡：
  可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
• 高可用基石：
  哨兵和集群基于主从复制。

主从复制启用方式

• 配置文件 在从服务器的配置文件中加入：slaveof
• 启动命令 redis-server启动命令后加入 --slaveof
• 客户端命令 Redis服务器启动后，直接通过客户端执行命令：slaveof ，则该Redis实例成为从节点。 通过 info replication 命令可以看到复制的一些参数信息

主从复制原理

3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。
在从节点执行 slaveof 命令后，复制过程便开始运作，复制过程大致分为6个过程

slave（slaveof）-》保存主节点信息-》主从建立socket连接-》发送ping命令-》权限验证-》同步数据集-》命令持续复制-》master 

• 保存主节点（master）信息。
• 从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接
• 连接建立成功后从节点发送 ping 请求进行首次通信，
• 权限验证：如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证
• 主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤
• 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

注意：主从在同步的过程当中，会把原本的从节点的数据清空

几个概念

全量复制

用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很 大的开销

部分复制 从redis2.8后才出现

用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果（条件允许)，主节点会补发丢失数据给从节点。 因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整地保存中断期间执行 的写命令，则无法进行部分复制，仍使用全量复制

复制偏移量

参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info relication 中的 master_repl_offset 指标中：

从节点（slave）每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量

从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在 info relication 中的 slave_repl_offset 中

复制积压缓冲区

复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令 时，不但会把命令发送给从节点，还会写入复制积压缓冲区。

在命令传播阶段，主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区，作为写命令的备份；除了存储写命令，复制积压缓冲区中还存储了其中 的每个字节对应的复制偏移量(offset) 。由于复制积压缓冲区定长且先进先出，所以它保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区()。

为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)来设置； 例如 如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见， 可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。

主从复制常见问题解决

读写分离 的 复制数据延迟

可能会出现 slave 延迟导致读写不一致等问题，当然你也可以使用监控偏移量 offset ，如果 offset 超出范围就切换到 master 上,逻辑切换，而具体延迟多 少，可以通过 info replication 的 offset 指标进行排查。 对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点 同时从节点的 slave-serve-stale-data 参数也与此有关，它控制这种情况下从节点的表现：如果为 yes （默认值），则从节点仍能够响应客户端的命令；如果 为 no ，则从节点只能响应 info、slaveof 等少数命令。该参数的设置与应用对数据一致性的要求有关；如果对数据一致性要求很高，则应设置为 no 。

从节点故障问题

对于从节点的故障问题，需要在客户端维护一个可用从节点可用列表，当从节 点故障时，立刻切换到其他从节点或主节点（redis Cluster可以解决 这个问题）
- 配置不一致

主从配置不一致 导致的数据丢失

主机和从机有时候会发生配置不一致的情况，例如 maxmemory 不一致，如果主机配置 maxmemory 为8G，从机 slave 设置为4G，这个时候是可 以用的，而且还不会报错。 但是如果要做高可用，让从节点变成主节点的时候，就会发现数据已经丢失了，而且无法挽回。

规避全量复制

• 全量复制指的是当 slave 从机断掉并重启后，runid 产生变化而导致需要在 master 主机里拷贝全部数据。这种拷贝全部数据的过程非常耗资源。

• 全量复制是不可避免的，例如第一次的全量复制是不可避免的，这时我们需要选择小主节点，且 maxmemory 值不要过大，这样就会比较快。同时选择在低峰值 的时候做全量复制。

• 造成全量复制的原因

• 1. 主从机的运行 runid 不匹配。解释一下，主节点如果重启， runid 将会发生变化。如果从节点监控到 runid 不是同一个，它就会认为你的节点不安全。 当发生故障转移的时候，如果主节点发生故障，那么从机就会变成主节点。
• 2. 复制缓冲区空间不足，比如默认值1M，可以部分复制。但如果缓存区不够大的话，首先需要网络中断，部分复制就无法满足。其次需要增大复制缓冲区配 置（relbacklogsize），对网络的缓冲增强。
• 3. 当一个主机下面挂了很多个 slave 从机的时候，主机 master 挂了，这时 master 主机重启后，因为 runid 发生了变化，所有的 slave 从机都要做一次全量 复制。这将引起单节点和单机器的复制风暴，开销会非常大。
• 4. 单机器的复制风暴 :由于 Redis 的单线程架构，通常单台机器会部署多个 Redis 实例。当一台机器（machine）上同时部署多个主节点 （master） 时，如果每个 master 主机只有 一台 slave 从机，那么当机器宕机以后，会产生大量全量复制。这种情况是非常危险的情况，带宽马上会被占用，会导致不可用。

• 全量复制的问题解决办法

• 1. 可以采用树状结构降低多个从节点对主节点的消耗 从节点采用树状树非常有用，网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种树状结构也带来了运维的复杂性，增加了手动和自动 处理故障转移的难度
• 2. 应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。
• 3. 当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制