redis 主从同步&哨兵模式

Redis主从同步

• 目的&作用：读写分离，保存redis数据副本，高可用，故障转移
• 复制方式
  1. 当master和slave正常连接时，master服务器会发送数据命令流将自身修改的数据发送给slave
  2. 全量同步
     • 在master和slave首次连接时触发
     • 从服务器连接主服务器后，发送psync命令
     • 主服务器接收到PSYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
     • 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
     • 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
     • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
     • 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
  3. 当master和slave因各种异常原因导致断开后，slave重新连接master后，会发送psync给master服务器，master会根据当前数据的来判断是全量同步还是部分同步，部分同步的实现原理如下：
     • 复制积压缓冲区
       • 复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB。
       • 当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。
       • 当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面
  • • 主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。
    • 当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：
      1. 如果offset偏移量之后的数据（也即是偏移量offset+1开始的数据）仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作；
      2. 相反，如果offset偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。
• 主从配置
  • 通过配置从服务器的redis配置文件redis.conf中的slaveof ip:port   来实现主从的配置
  • master服务器如果有验证的话，通过配置文件redis.conf中的masterauth password来实现
  • 只读模式配置   slave-read-only yes/no 

Redis哨兵模式

• 作用：当主服务器因各种原因导致不可用，redis的写操作和同步操作无法进行，为了避免这种情况，可以在主服务器异常后重新选取一台从服务器作为主服务器使用，并通知到客户端，redis提供了Sentinel（哨兵）模式，哨兵为运行在特殊模式下的redis进程。
• 哨兵模式配置
  • 通过redis-sentinel.conf配置文件中的sentinel monitor <master name> <ip> <port> <quorum>来定位监听的master，通过配置多个sentinel monitor来监听多了master
  • 哨兵启动后，会与要监控的master建立两条连接：
    1. 一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息
    2. 另一条连接定期向master发送INFO等命令获取master本身的信息
  • 与master建立连接后，哨兵会执行三个操作：
    1. 定期（一般10s一次，当master被标记为主观下线时，改为1s一次）向master和slave发送INFO命令
    2. 定期向master和slave的_sentinel_:hello频道发送自己的信息
    3. 定期（1s一次）向master、slave和其他哨兵发送PING命令
  • 哨兵向主从数据库的_sentinel_:hello频道发送信息与同样监控这些数据库的哨兵共享自己的信息，发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处：
    • 其他哨兵可以通过该信息判断发送者是否是新发现的哨兵，如果是的话会创建一个到该哨兵的连接用于发送PING命令。
    • 其他哨兵通过该信息可以判断master的版本，如果该版本高于直接记录的版本，将会更新
    • 当实现了自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。
  • 被PING的数据库或者节点超时（sentinel down-after-milliseconds master-name milliseconds 配置）未回复，哨兵认为其主观下线（sdown，s就是Subjectively —— 主观地）
  • 如果下线的是master，哨兵会向其它哨兵发送命令询问它们是否也认为该master主观下线，如果达到一定数目（即配置文件中的quorum）投票，哨兵会认为该master已经客观下线（odown，o就是Objectively —— 客观地），并选举领头的哨兵节点对主从系统发起故障恢复。若没有足够的sentinel进程同意master下线，master的客观下线状态会被移除，若master重新向sentinel进程发送的PING命令返回有效回复，master的主观下线状态就会被移除
  • 哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵来执行，选举采用Raft算法：
    • 发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵
    • 如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵
    • 如果有超过一半的哨兵同意选举A为领头，则A当选
    • 如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票竞选，直至选举出领头哨兵
  • 选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master,选择规则如下:
    1. 所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置
    2. 如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选
    3. 如果以上条件都一样，选取id最小的slave
  • 挑选出需要继任的slave后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行