Redis高可用架构Sentinel介绍

第1集 灾备切换Sentinel的使用

简介：互联网服务灾备故障转移，sentinel的配置

• Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

  • 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
  • 扩展主节点的读能力，分担主节点读压力。

  但是问题来了：

  • 一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。

• redis主节点挂掉之后应该怎么操作？命令模拟

slaveof no one       # 取消主备，变更为主节点
slaveof 新host  新节点  # 将其他节点设置为新主节点的备份节点

• Sentinel正是实现了这个功能

• 开启Sentinel配置 3主3从 3主6从

sentinel monitor mymaster 127.0.0.1 6379 1   
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

• 命令讲解

  • sentinel monitor mymaster 127.0.0.1 6379 1 名称为mymaster的主节点名，1表示将这个主服务器判断为失效至少需要 1个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
  • down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数
  • failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel 将会认为此次failoer失败
  • parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
  • 如果从服务器被设置为允许使用过期数据集， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

• 启动所有主从上的sentinel

  • 前提是它们各自的server已成功启动 cd /usr/local/redis/src/redis-sentinel /etc/redis/sentinel.conf

• info Replication 查看节点信息

• shutdown主节点看服务是否正常

进行测试：

sentinel运行时候，将主节点shutdown之后，sentinel觉察到之后会重新选举 sentinel投票给6380，并将6379fail over，之后6380成为主节点

之后我们重新查看进程发现已经没有6379的进程，sentinel进程号比redis进程大20000:

重新查看进程

另我们重新登陆6380端口，并使用info replication命令查看，会发现6380成为master节点，6381成为其slave节点，这一些都是sentinel帮我们做好的。

image.png

互联网高可用灾备以及Sentinel三大任务讲解

简介：互联网冷备和热备讲解，Sentinel是怎么工作的？Sentinel三大工作任务是什么？

sentinel做的事情

• Sentinel三大工作任务

  • 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

• 互联网冷备和热备讲解，冷备和热备的特点分析

  • 冷备
    • 概念：冷备份发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库
    • 优点：
      • 是非常快速的备份方法（只需拷文件）
      • 低度维护，高度安全
    • 缺点：
      • 单独使用时，只能提供到“某一时间点上”的恢复
      • 再实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是说，在冷备份过程中，数据库必须是关闭状态
  • 热备
    • 概念：热备份是在数据库运行的情况下，采用archivelog mode方式备份数据库的方法
    • 优点：
      • 备份的时间短
      • 备份时数据库仍可使用
      • 可达到秒级恢复
    • 缺点
      • 若热备份不成功，所得结果不可用于时间点的恢复
      • 因难于维护，所以要非凡仔细小心

热备份和冷备份

Redis高可用Sentinel故障转移原理

简介：Sentinel是怎么工作的？

• 主观下线：

  • 概念主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断

  • 主管下线特点：

    • 如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记为主观下线

    • 服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：

返回 +PONG 。
返回 -LOADING 错误。
返回 -MASTERDOWN 错误。

• 客观下线

  • 客观下线概念：

    • 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

  • 客观下线特点：

    • 从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum algorithm），而是使用了流言协议： 如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移除。

  • 客观下线注意点：

    • 客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

sentinel整合Springboot实战

简介：Redis高可用整合springboot讲解

• 思考？redis高可用sentinel整合springboot的步骤

高可用架构

图解高可用架构代理的概念，sentinel相当于redis的代理，SpringBoot只需要链接sentinel

sentinel相当于redis的代理

• 引入yml配置文件

redis:
      sentinel:
         master: redis_master_group1    #mymaster
         nodes: 172.16.244.133:26379

• pom文件

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

• 启动springboot服务

• 登上服务器看配置是否有效

  
  代码

浏览器测试 查看修改是否有效 已经写入