这次彻底读透 Redis !( 七 )

  • 主数据库快照发送完毕后开始向从数据库发送缓冲区中的写命令;
  • 从数据库完成对快照的载入,开始接收命令请求,并执行来自主数据库缓冲区的写命令;(从数据库初始化完成
  • 主数据库每执行一个写命令就会向从数据库发送相同的写命令,从数据库接收并执行收到的写命令(从数据库初始化完成后的操作
  • 出现断开重连后,2.8之后的版本会将断线期间的命令传给重数据库,增量复制 。
  • 主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步 。当然,如果有需要,slave 在任何时候都可以发起全量同步 。Redis 的策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步 。
  •  
    主从复制优缺点
    优点
     
    • 支持主从复制,主机会自动将数据同步到从机,可以进行读写分离
    • Slave 同样可以接受其它 Slaves 的连接和同步请求,这样可以有效的分载 Master 的同步压力
    • Master Server 是以非阻塞的方式为 Slaves 提供服务 。所以在 Master-Slave 同步期间,客户端仍然可以提交查询或修改请求
     
    缺点
     
    • 主从不具备容错和恢复能力,一旦主机挂了,那么整个集群处理可读状态,无法处理写请求,会丢失数据
    • 主机宕机后无法自动恢复,只能人工手动恢复
    • 集群存储容量有限,容量上线就是主库的内存的大小,无法存储更多内容
     
    ###哨兵集群
    哨兵概念
    哨兵,我们经常在电视剧中看到一些放哨的,哨兵的作用和这些放哨的差不多,起到监控作用 。一旦 Redis 集群出现问题了,哨兵会立即做出相应动作,应对异常情况 。
    哨兵模式是基于主从复制模式上搭建的,因为主从复制模式情况下主服务器宕机,会导致整个集群不可用,需要人工干预,所以哨兵模式在主从复制模式下引入了哨兵来监控整个集群,哨兵模式架构图如下:
    这次彻底读透 Redis !

    文章插图
     
    哨兵功能
    监控(Monitoring):哨兵会不断地检查主节点和从节点是否运作正常 。
    自动故障转移(Automatic failover):当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点 。
    配置提供者(Configuration provider):客户端在初始化时,通过连接哨兵来获得当前Redis服务的主节点地址 。
    通知(Notification):哨兵可以将故障转移的结果发送给客户端 。
    下线判断
    Redis 下线分为主观下线和客观下线两种
     
    • 主观下线:单台哨兵任务主库处于不可用状态
    • 客观下线:整个哨兵集群半数以上的哨兵都认为主库处于可不用状态
     
    哨兵集群中任意一台服务器判断主库不可用时,此时会发送命令给哨兵集群中的其他服务器确认,其他服务器收到命令后会确认主库的状态,如果不可用,返回 YES,可用则返回 NO,当有半数的服务器都返回 YES,说明主库真的不可用,此时需要重新选举
    这次彻底读透 Redis !

    文章插图
     
    主库选举
    当哨兵集群判定主库下线了,此时需要重新选举出一个新的主库对外提供服务 。那么该由哪个哨兵来完成这个新库选举和切换的动作呢?
     
    注意:这里不能让每个哨兵都去选举,可能会出现每个哨兵选举出的新主库都不同,这样就没法判定,所以需要派出一个代表
     
    哨兵代表选择
    哨兵的选举机制其实很简单,就是一个Raft选举算法:选举的票数大于等于num(sentinels)/2+1时,将成为领导者,如果没有超过,继续选举