Redis的主从复制和哨兵模式

一、主从复制

主从复制是指将一台Redis服务器的数据，复制到其他Redis服务器。前者称为主节点(master/leader)后者称为从节点(slave/follower)，默认情况下所有服务器都是主节点。数据的复制是单向的，只能由主节点到从节点，Master以写为主，Slave 以读为主。一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

1. 主从复制的作用

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

2. 主从复制的原理

Slave启动成功并连接到 master 后会发送一个psync同步命令，Master 接到命令，启动后台的存盘进程(bgsave命令)，同时收集所有接收到的写命令，在后台的存盘进程执行完毕之后，master会将整个RDB数据文件传送到slave，等 RDB 文件传输完成并且在从节点加载完成后 //全量复制 ，主节点再把复制缓冲区中的写命令发给从节点，进行同步 //增量复制。

全量复制：slave服务在接收到RDB数据文件后，会将其存盘并加载到内存中。

增量复制：Master 继续将所有收集到的修改命令依次传给slave，完成同步。但只要是slave重新连接master，一次完全同步（全量复制）将被自动执行。

复制缓冲区(replication_buffer ) ：

• 主节点上会为每个从节点都维护一个复制缓冲区，来保证主从节点间的数据同步
• 在全量复制的过程中，master会继续接收客户端发送的写命令请求，这些命令会先保存在复制缓冲区中，在全量复制完成之后，再同步给主节点
• 如果复制缓冲区发生溢出该怎么办？
  • 如果在全量复制的时，从节点接收和加载 RDB 较慢，同时主节点接收到了大量的写命令，写命令在复制缓冲区中就会越积越多，最终导致溢出
  • 复制缓冲区一旦发生溢出，主从节点也会直接关闭和从节点进行复制操作的连接，导致全量复制失败，并重新开始全量同步
  • 可以控制主节点保存的数据量大小，按通常的使用经验，我们会把主节点的数据量控制在 2~4GB，这样可以让全量同步执行得更快些，避免复制缓冲区累计过多命令
  • 可以使用 client-ouput-buffer-limit 配置项，来设置合理的复制缓冲区大小，设置的依据就是主节点数据量大小、主节点的写负载压力和主节点本身的内存大小。例如：配置 config set client-output-buffer-limit slave 512mb 128mb 60，其中 slave表示该配置是针对复制缓冲区的，512mb 表示将缓冲区大小的上限设置为 512MB，128mb 60 表示如果连续 60 秒内写入的量超过 128MB 的话，也会触发缓冲区溢出
  
  

runid: redis服务器的随机标识符，重启后就会改变；当数据同步时发现和之前的 run_id 不同时，将会对数据全量复制

offset:

• 名称：复制偏移量
• 作用：记录复制缓冲区中指令字节的位置
• 分类：
  • 参与复制的主从节点都会维护自身复制偏移量，主节点在处理完写入命令操作后，会把命令字节的长度做累加记录，统计信息在info replication中的master_repl_offset指标中。
  • 从节点每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量slave0:ip=192.168.1.3,port=6379,state=online,offset=116424,lag=0
  • 从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info replication中的slave_repl_offset中
• 作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用
  

主从连接之后的整体复制流程：

• master生成复制缓冲区
• slave发送指令：psync2 ? -1 (意思需要全部信息)
• master接收到指令，执行bgsave生成RDB文件，记录当前的复制偏移量offset (master_repl_offset)
• 之后master将runid 和offset(master_repl_offset)发给slave。发送 +FULLRESYNC runid offset命令，(全量复制)，通过socket发送RDB文件给slave
• slave收到 +FULLRESYNC(全量复制)，保存master的runid和offset，清空当前全部数据，通过socket接收RDB文件，恢复RDB数据
• 在整个过程中有一些指令要进入复制缓冲区，master接收这些客户端指令，offset发生了变化
• slave 发送命令：psync2 runid offset（这里的offset代表的是某一时刻的主节点master_repl_offset）
• master 接收命令，判断runid是否匹配，判定offset是否在复制缓冲区中
• 如果runid或offset有一个不满足，执行全量复制（循环之前的全量复制）
• 如果runid或offset校验通过，offset与offset(master_repl_offset)相同，则忽略
• 如果如果runid或offset校验通过，offset与offset(master_repl_offset)不相同。
• 就发送 +CONTINUE offset(master_repl_offset)。
• 通过socket发送复制缓冲区中offset到offset(master_repl_offset)的数据
• slave 收到 +CONTINE
• 保存master的offset(master_repl_offset)
• 接收到信息后，执行bgrewriteaof，恢复数据

3.总结

• 全量复制用于slave第一次同步master数据。主节点会fork出一个进程进行RDB备份，之后将RDB文件和复制缓冲区的数据发送给slave完成数据同步。
• 增量复制用于第一次同步之后的数据同步，这时候只需要同步缓冲区里面新增的写命令即可

二、哨兵模式

Sentinel的配置文件:

port 26379

#以守护模式运行
daemonize yes

protected-mode no

#存放备份文件以及日志等文件的目录
dir /opt/redis

#日志文件名
logfile "26379.log"

#<mymaster-name> 自己命名的主节点的名字
#sentinel所监控的主节点的监控的IP 端口号
#至少有<quorum>个哨兵认为主节点主观下线，才认为主节点客观下线
sentinel monitor <mymaster-name> <ip> <port> <quorum>

# 判定节点下线(失联)的时间间隔，单位是毫秒。
sentinel down-after-milliseconds mymaster 5000  

# 主节点的密码配置
sentinel auth-pass <mymaster-name> <password>

# 在故障转移时，可以同时与新的主节点进行主从复制的从节点的最大个数
# 如果设置过大，大量从节点在主从复制时不能对外提供服务
# 如果设置过小，完成故障转移的时间就会越长(failover)
sentinel parallel-syncs mymaster 1  

# 故障转移的超时时间
# 当超过这个时间则认为故障转移失败
sentinel failover-timeout mymaster 50000  

工作模式:

• 1.每个Sentinel（哨兵）进程以每秒钟一次的频率向集群中的所有服务器以及其他Sentinel(哨兵) 进程发送一个 PING 命令

• 2.如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过配置文件中 down-after-milliseconds 选项所设置的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）

• 3.一旦某个sentinel发现master没有正常的响应，sentinel将此master置为“主观下线状态,并将 “主观下线”猜想发送给其他所有的sentinel节点进行确认（is-master-down-by-addr），当确认的sentinel节点数 >= quorum(配置文件)时，则判定该master 为客观下线（ODOWN）
  

• 4.当Master主服务器客观下线时， Sentinel 会开始执行故障转移操作

• 5.若没有足够数量 的 Sentinel（哨兵）进程认为 Master服务器主观下线，只要 Master服务器重新向 Sentinel（哨兵）进程发送的PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除

• 6.在一般情况下， 每个Sentinel（哨兵）进程会以每十秒钟一次的频率 向集群中的所有服务器发送 INFO命令(确定主从关系)

• 7.当Master服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master服务器的所有 Slave服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次

Sentinel之间的相互感知:
  sentinel进程之间因为共同监视了同一个master节点，从而也关联了起来。一个新加入的sentinel进程，需要和其它监视相同master服务器的sentinel进程相互感知。感知方式如下：所有需要相互感知的sentinel进程都会订阅它们所共同监视的master服务器上的同一个channel：sentinel:hello；新加入的sentinel节点向这个channel发布一条消息，包含了自己的信息，该channel的订阅者们就可以发现这个新的sentinel，随后新的sentinel就会和已有的其他sentinel建立长连接。之后以每秒钟两次的频率每个Sentinel通过master节点的channel交换信息（通过__sentinel__:hello频道交互；交互对节点的“看法”和自身信息）具体流程如下所示：

Sentinel的leader选举：

• 参考博文

故障转移：

1. 从slave节点中选出一个“合适的”节点作为新的master节点(流程如下)：
   • 选择slave-priority（slave节点优先级）最高的节点，如果存在则返回，不存在则继续
   • 选择复制偏移量最大的slave节点（数据完整性最高），如果存在则返回，不存在则继续
   • 选择runId最小的slave节点（最先启动的）
2. 对上面的slave节点执行 salveof no one 命令，让其成为master节点
3. 向剩余的slave节点发送命令，让它们成为新的master的slave，复制规则和parallel-syncs参数有关
4. 更新旧的master节点的角色为slave，并保持对其关注，当其恢复后命令其去复制新master节点的内容