Redis Sentinel-高可用

版权声明：本文为博主原创文章，转载请注明出处 https://blog.csdn.net/love905661433/article/details/82289928

Redis Sentinel架构

Redis Sentinel故障转移

1. 多个sentinel发现并确认master有问题
2. 选举一个sentinel作为领导
3. 选出一个slave作为master
4. 通知其余slave成为新的master的slave
5. 通知客户端主从变化
6. 等待老的master复活成为新的slave

故障转移前:

故障转移后:

Redis Sentinel安装与配置

• 配置开启主从节点
• 配置开启sentinel监控主节点(sentinel是特殊的redis)

Sentinel主要配置

• port : 端口号

• dir : 工作目录

• logfile “${port}.log” : 日志文件名

• sentinel monitor mymaster 127.0.0.1 6379 2

  **命令格式 : **sentinel monitor [masterName] [ip] [port] [quorum]

  参数说明:

  masterName : 要监控的Redis主节点名称

  ip : 要监控的Redis主节点ip

  port: 要监控的Redis主节点端口号

  quorum : 几个sentinel认为主节点不可用才出发故障转移,2表示有两个sentinel节点认为主节点不可用才会进行故障转移操作

• sentinel down-after-milliseconds mymaster 30000 :

  指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行

• sentinel parallel-syncs mymaster 1 :
  

  指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长

• sentinel failover-timeout mymaster 180000 : 如果在该时间（ms）内未能完成failover操作，则认为该failover失败

Sentinel客户端

客户端实现基本原理


客户端接入流程

• Sentinel地址集合
• masterName
• 不是代理模式

Jedis连接Sentinel

    @Test
    public void testSentinel(){
        Set<String> sentinels = new HashSet<String>();
        // 这个地址是我本地虚拟机地址
        sentinels.add("192.168.72.129:26379");
        sentinels.add("192.168.72.129:26380");
        sentinels.add("192.168.72.129:26381");
        JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);
        Jedis jedis = null;
        try {
            jedis = pool.getResource();
            System.out.println(jedis.ping()) ;
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
    }

定时任务

每10秒每个sentinel对master和slave执行info

• 发现salve节点
• 确认主从关系

每2秒每个sentinel通过master节点的channel交换信息(pub/sub)

• 通过__sentinel__:hello频道交互
• 交互对节点的”看法”和自身信息

每1秒每个sentinel对其他sentinel和redis执行ping

• 心跳检测,失败判定依据

主观下线和客观下线

主观下线

每个sentinel节点对Redis节点失败的”偏见”

客观下线

所有sentinel节点对Redis节点失败”达成共识”,超过quorum个统一

领导者选举

• 原因 : 只有一个sentinel节点完成故障转移
• 选举 : 通过sentinel is-master-down-by-addr命令都希望成为领导者
  
  • 每个做主观下线的sentinel节点向其他Sentinel节点发送命令,要求将它设置为领导者
  • 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令,那么将同意该请求,否则拒绝
  • 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者
  • 如果此过程有多个Sentinel节点成为领导者, 那么将等待一段时间重新进行选举

故障转移(sentinel领导者节点完成)

• 从slave节点中选出一个”合适的”节点作为新的master节点
• 对上面的slave节点执行slaveof no one命令其成为master节点
• 向剩余的slave节点发送命令, 让它们成为新master节点的slave节点, 复制规则和parallel-syncs参数有关
• 更新对原来master节点的配置为slave, 并保持着对其”关注”, 当其恢复后命令它去复制新的master节点

选择”合适的”slave节点 :

• 选择slave-priority(slave节点优先级)最高的节点, 如果存在则返回, 不存在则继续
• 选择复制偏移量最大的slave节点(复制的最完整), 如果存在则返回, 不存在则继续
• 选择runId最小的slave节点(最早启动的节点)

开发运维常见问题

节点运维

• 机器下线
• 机器性能不足
• 节点自身故障

节点下线

主节点下线 :

• sentinel failover masterName : 对主节点执行这个命令进行手动故障转移

  

从节点下线 :

临时下线还是永久下线, 例如是否做一些清理工作

需要考虑读写分离的情况

Sentinel节点 : 同上,不需要考虑读写分离

节点上线

• 主节点 : sentinel failover进行替换
• 从节点 : slaveof即可, sentinel节点可以感知
• sentinel节点 : 参考其他sentinel节点启动即可

高可用读写分离

从节点的作用 :

• 副本 : 高可用的基础
• 扩展 : 读能力

读写分离需关注消息 :

• +switch-master : 切换主节点(从节点晋升主节点)
• +convert-to-slave : 切换从节点(原主节点降为从节点)
• +sdown : 主观下线

主要实现方式如下图:

将所有从节点放在一个资源池中,客户端只访问资源池获取资源

Sentinel总结

• Redis Sentinel是Redis的高可用实现方案 : 故障发现, 故障自动转移, 配置中心, 客户端通知
• Redis Sentinel是Redis2.8版本开始才正式生产可用, 之前版本生产不可用
• 尽可能在不同的物理机上部署Redis Sentinel所有节点
• Redis Sentinel中的Sentinel节点个数应该大于等于3且最好为奇数
• Redis Sentinel中的数据节点与普通数据节点没有区别
• 客户端初始化时连接的是Sentinel节点集合, 不再是具体的Redis节点, 但Sentinel只是配置中心不是代理
• Redis Sentinel通过三个定时任务实现了Sentinel节点对于主节点, 从节点, 其余Sentinel节点的监控
• Redis Sentinel在对节点做失败判定时分为主观下线和客观下线
• 看懂Redis Sentinel故障转移日志对于Redis Sentinel以及问题排查非常有帮助
• Redis Sentinel实现读写分离高可用可以依赖Sentinel节点的消息通知, 获取Redis数据节点的状态变化