redis主从复制实现（操作记录）

redis主从复制

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

默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复
• 负载均衡：提高并发量
• 读写分离：从库（slave）不可写

开启主从的3中方式

• 配置文件：在从服务器的配置文件中加入：slaveof
• redis-server启动命令后加入 --slaveof
• 通过客户端：slaveof
  
  
  

主从复制原理

1. 连接建立阶段（即准备阶段）
2. 数据同步阶段
3. 命令传播阶

在从节点接收到slave命令后：

1. 保存主节点（master）信息
2. 尝试与主节点建立网络连接（如不同则会一直重试，直到slaveof no one【取消主从关系】）
3. 发送ping命令，确定连接是否可用
4. 权限验证，在主节点的配置文件中 requirepass 如设置密码 ，从节点 masterauth需配置同样密码才可通过验证
5. 同步数据，第一次为全量复制，下面会详细说明
6. 命令持续复制，保持主从节点数据的一致性

注意：在主从同步时，从节点数据会清空

全量复制，部分复制

全量复制：用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很
大的开销
部分复制：用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果（条件允许)，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整地保存中断期间执行
的写命令，则无法进行部分复制，仍使用全量复制
复制偏移量：参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info relication 中的
master_repl_offset 指标中：

主节点同样会记录累计的偏移量：

全量复制执行步骤：

1. Redis 内部会发出一个同步命令，刚开始是 Psync 命令，Psync ? -1表示要求 master 主机同步数据
2. 主机会向从机发送 runid 和 offset，因为 slave 并没有对应的 offset，所以是全量复制
3. 从机 slave 会保存 主机master 的基本信息 save masterInfo
4. 主节点收到全量复制的命令后，执行bgsave（异步执行），在后台生成RDB文件（快照），并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
5. 主机send RDB 发送 RDB 文件给从机
6. 发送缓冲区数据
7. 刷新旧的数据，从节点在载入主节点的数据之前要先将老数据清除
8. 加载 RDB 文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。

全量复制开销：

• bgsave 时间
• RDB 文件网络传输时间
• 从节点清空数据的时间
• 从节点加载 RDB 的时间

部分复制执行步骤：

1. 如果网络抖动（连接断开 connection lost）
2. 主机master 还是会写 replbackbuffer（复制缓冲区）
3. 从机slave 会继续尝试连接主机
4. 从机slave 会把自己当前 runid 和偏移量传输给主机 master，并且执行 pysnc 命令同步
5. 如果 master 发现你的偏移量是在缓冲区的范围内，就会返回 continue 命令
6. 同步了 offset 的部分数据，所以部分复制的基础就是偏移量 offset。

从部分复制的第5条能看出，若偏移量在缓冲区范围内则进行部分复制，那么偏移量如果超过复制缓冲区（一定长度的队列，先进先出），那么则执行全量复制。

复制缓冲区大小可以通过配置文件(redis.conf)中的repl-backlog-size来进行设置：

服务器运行ID(runid):每次redis启动时都会自动生成一个随机ID

主从节点初次复制时，主节点将自己的runid发送给从节点，从节点将这个runid保存起来；当断线重连时，从节点会将这个runid发送给主节点；主节点根据runid判断能否进行部分复制

如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)

如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。

主从复制常见问题，解决方式

我们知道全量复制的开销是非常大的，所以我们在日常的开发中要尽量避免这种情况（第一次无法避免）。从上面的内容我们可以了解到，runid可以当做是是否进行全量复制的标识，也就是如果主节点进行重启的话，那么runid必定发生改变，如主从节点部署为：

则3个从节点都需要进行全量复制，那么主节点的开销将非常大，所以我们可以将上面的部署方式进行修改：

采用树状结构降低多个从节点对主节点的消耗，使其网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种树状结构也带来了运维的复杂性，增加了手动和自动处理故障转移的难度。

同时为了防止在一台机器上进行多次的全量复制，导致宕机：

1. 应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。
2. 当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制

从库
#设置该数据库为其他数据库的从数据库
slaveof
#主从复制中，设置连接master服务器的密码（前提master启用了认证）
masterauth
slave-serve-stale-data yes
当从库同主库失去连接或者复制正在进行，从库有两种运行方式：

1. 如果slave-serve-stale-data设置为yes(默认设置)，从库会继续相应客户端的请求
2. 如果slave-serve-stale-data设置为no，除了INFO和SLAVOF命令之外的任何请求都会返回一个错误"SYNC with master in progress"

#当主库发生宕机时候，哨兵会选择优先级最高的一个称为主库，从库优先级配置默认100，数值越小优先级越高
slave-priority 100
#从节点是否只读；默认yes只读，为了保持数据一致性，应保持默认
slave-read-only yes

主库配置
#在slave和master同步后（发送psync/sync），后续的同步是否设置成TCP_NODELAY假如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致假如设置成no，则redis master会立即发送同步数据，没有延迟。

#前者关注性能，后者关注一致性

repl-disable-tcp-nodelay no

#从库会按照一个时间间隔向主库发送PING命令来判断主服务器是否在线，默认是10秒

repl-ping-slave-period 10

#复制积压缓冲区大小设置

repl-backlog-size 1mb

#master没有slave一段时间会释放复制缓冲区的内存，repl-backlog-ttl用来设置该时间长度。单位为秒。

repl-backlog-ttl 3600

#redis提供了可以让master停止写入的方式，如果配置了min-slaves-to-write，健康的slave的个数小于N，mater就禁止写入。master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都一定能接收到master的写操作，但是能避免没有足够健康的slave的时候，master不能写入来避免数据丢失。设置为0是关闭该功能。

min-slaves-to-write 3
min-slaves-max-lag 10