redis-哨兵

1.基本介绍

在介绍redis主从主从复制的时候，提到了相对于单机的redis架构，主从复制架构具有如下优势:

• 保证数据安全性。从节点作为主节点备份，一旦主节点不可用，从节点可以顶上去，保证了数据尽量不被丢失。
• 提高读能力。主从读写分离，横向扩展的系统的读负载
• redis高可用的基础

但是主从复制架构有一个非常致命的问题，那就是一旦主节点由于故障不可用时，需要手动将一个从节点晋升为主节点，需要将其他节点替换为新的主节点，同时还需要修改应用的主节点地址，如果应用方没使用配置中心则还需要重启服务，整个过程都需要人工干预，而且

工程量也不小，这是一个无法接受的问题。幸好，在 Redis 2.8 提供比较完善的解决方案：Redis Sentinel。 Redis Sentinel 是一个能够自动完成故障发现和故障转移并通知应用方，从而实现真正的高可用的分布式架构 。下面是Redis官方文档对于哨兵功能的描述：

• 监控（Monitoring） ：哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover） ：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider） ：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知（Notification） ：哨兵可以将故障转移的结果发送给客户端。

监控和自动故障转移使得 Sentinel 能够完成主节点故障发现和自动转移，配置提供者和通知则是实现通知客户端主节点变更的关键。

2.架构

典型的哨兵架构图如上图所示，它主要包括两个部分：哨兵节点和数据节点。

• 哨兵节点：哨兵系统由若干个哨兵节点组成。其实哨兵节点就是一个特殊的 Redis 节点，只不过它是不存储数据的和仅支持部分命令
• 数据节点：由主节点和从节点组成的数据节点。

部署

哨兵部署

上面介绍了典型的哨兵架构包括了哨兵节点和数据节点，所以这里我们分为两步部署。

部署 Redis 数据节点

部署 Redis 数据节点其实就是部署主从架构，按照我们上面的要求是一主两从的架构。

3.基本流程

1. 配置一主

   6379 是我们的主节点，配置如下：

    --redis-6379.conf
   
           port 6379
           daemonize yes
           pidfile "/var/run/redis_6379.pid"
           logfile "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/6379/redis.log"
           dir "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/6379"
   

   2.两从

   两个从节点的配置和主节点基本一致，如下：

     --redis-6380.conf
   
           port 6380
           daemonize yes
           pidfile "/var/run/redis_6380.pid"
           logfile "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/6380/redis.log"
           dir "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/6380"
           slaveof 127.0.0.1 6379
   

   启动 6380 和 6381 两个节点，这时他们与 6379 已经建立了主从关系，从 6379 视角看，它有两个从节点 6380、6381，如下：

   

   此时得拓扑序列：

   

   3.部署Sentinel节点

   3 个 Sentinel 节点的部署方式完全一致，仅仅只是端口不同，下面只演示 26379 节点的部署。

     -- redis-26379.conf
           port 26379
           daemonize yes
           pidfile "/var/run/redis_26379.pid"
           logfile "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/26379/redis.log"
           dir "/Users/chenssy/Documents/workSpace/environment/redis-5.0.3/26379"
   
           sentinel monitor mymaster 127.0.0.1 6379 2
   

   sentinel monitor mymaster 127.0.0.1 6379 2，表示的意义是该哨兵节点监控 127.0.0.1:6379 这个主节点，mymaster 是主节点的别名，最后的 2 的含义是至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

   哨兵节点的启动有两种方式：

       redis-sentinel ../26379/redis-26379.conf
           redis-server ../26379/redis-26379.conf --sentinel
   

   4.故障转移演示

   我们先来回想下在主从架构模式下，当主节点发生故障后，我们是如何手动恢复的呢？

   1. 我们选定一个从节点对其执行 slaveof no one 命令，使其变成一个新的主节点
   2. 将其他从节点变成新主节点的从节点，执行命令 slaveof 新IP 新port
   3. 更新客户端的 Redis 连接信息，重启应用
   4. 启动发送了故障的主节点，执行 slaveof 新IP 新port 使其变成新主节点的从节点

   上面的过程都需要人工干预，同时也会存在几个问题，比如我们是如何发送主节点故障了呢？判断主节点故障的机制是否完善？选择从节点的机制是否完善呢？等等一系列的问题，所以对于这种方案在生产环境下我们肯定是不可能接受的，那么如何解决呢？Redis Sentinel 就是解决这些问题的方案，下面就 Redis Sentinel 是如何实现故障转移的流程做一个简要的说明。

   1. 主节点出现故障导致不可用，这时从节点和客户端都与其失去联系
   2. Sentinel 节点通过定时监控发现主节点出现了故障，判断其不可用（可能是某个节点主观认为不可用），当大多数 Sentinel 对主节点的故障判断达成一致时，就会选举一个 Sentine-l 节点作为领导者来负责故障转移
   3. Sentinel-1 通过一定规则选择其中一个从节点作为新的主节点，然后整个过程就和上面手动恢复一致了，只不过它是又 sentinel-1 来自动完成的。

   故障转移后，上图架构变成了下图所示：

   

参考:https://www.cmsblogs.com/article/1391390885291364352