Redis-05 Redis哨兵高可用架构原理与搭建

        上文末指出，Redis【主-从】架构的从节点一般仅用于读操作，或纯粹数据备份，这种架构当主节点宕机时，Redis服务将不可用，需重启主节点或手动将从节点升级为主节点以接收写操作。无论采用那种方式都不可保证Redis服务的可用性。故Redis提供了【哨兵】机制，相较于单纯的【主-从】架构，哨兵机制可在Redis主节点宕机后，自动选出可用节点并升级为主节点，供客户端使用。选举和升级时长可配置，一般默认为30s~3min，极大增加了【主-从】架构的可用性。

1，哨兵架构搭建

        Redis哨兵仍然是Redis服务，是专门用来监控其他哨兵和主从Redis服务运行状态的Redis服务，配置文件是Redis安装目录下的sentinel.conf文件，启动使用src下redis-sentinel服务启动，哨兵结构图如下：

        注意：哨兵机制的核心是自动选举。目前市面上所有架构的选举机制，基本都采用了【过半同意机制】，即参与选举的所有哨兵中，当出现超过半数的哨兵选举结果一致时，该结果就是最终结果。

        比如：假设有三台Redis服务：A(主), B(从), C(从)，另外有三台哨兵服务D, E, F。当A宕机后，DEF需要从BC中选出一台作为master。如果DEF中任意两个选的结果相同，该结果就会是master，比如DE选择C，F选择B，则C将作为master对外提供服务，B则变为C的从节点。

        1.1，搭建步骤

        搭建三台Redis服务实现一主两从（步骤见上章），搭建三个哨兵（一般搭建奇数哨兵，方便选举）：

1，复制sentinel.conf文件，分别为sentinel-26379.conf, sentinel-26380.conf, sentinel-26381.conf

        cp  redis-5.0.0  redis-5.0.0/config/sentinel/sentinel-26379.conf 

2，修改配置文件（属性作用将在1.2详解）

        port  26379

        daemonize  yes   // 后台运行程序

        pidfile  var/run/redis-sentinel-26379.pid

        logfile  "redis-5.0.0/logs/redis-sentinel-26379.log"

        dir  redis-5.0.0/data/26379

        sentinel monitor mymaster 192.168.122.1 6379 2

3，启动Redis服务、启动哨兵

        src/redis-server  config/master-slave/6379.conf

        src/redis-sentinel  config/sentinel/sentinel-26379.conf

        至此，哨兵的架构既已搭建完成。登录6379客户端，通过【info】 命令，可查看当前Redis服务的主从节点信息，如下图：

        

        哨兵架构搭建好后，系统会将当前节点信息记录在各哨兵配置文件，如下图为sentinel-26379.conf：

        1.2，sentinel 配置属性详解        

        哨兵配置后的sentinel.conf文件与哨兵配置前文件有明显不同，配置后除了记录各节点信息，还记录了主节点的选举切换次数等。下面将介绍哨兵配置前后各参数作用：

        1.2.1，哨兵配置前属性

sentinel  monitor  <master-name>  <ip>  <redis-port>  <quorum>

sentinel  monitor  mymaster  192.168.122.1  6379  2

        设置哨兵监控的主节点对象，哨兵可从主节点获取所有从节点信息【info replication】

        <master-redis-name> : 主节点名称，可任意设置值，客户端访问时会用到；

        <master-redis-ip>、<master-redis-port>：主节点IP、端口；

        <quorum>: 哨兵选举成功个数。表示当有多少个哨兵认为master宕机时，才表示master真的宕机，修改master运行状态。一般设置个数值为：哨兵个数/2 + 1

sentinel  down-after-milliseconds  <master-name>  <milliseconds>

sentinel  down-after-milliseconds  30000

        判断节点是否宕机的时间阈值。默认情况下，每个哨兵会以每秒一次的频率向各Redis节点及其他哨兵发送PING命令（心跳机制），通过返回的结果判断对方是否在线，若回复超过该参数设定时间，则判断对方已下线。

sentinel  parallel-syncs  <master-name>  <numreplicats>

sentinel  parallel-syncs  mymaster  1

         新的master选举成功后，从节点将从主节点复制数据。该参数表示新master上线后，同时复制master数据的从节点的个数，即并行复制master数据的从节点个数。

sentinel  failover-timeout  <master-name>  <millseconds>

sentinel  failover-timeout  mymaster  180000

        master故障后，故障转移超时时间，超过该值表示当前次master故障转移失败，需重新选举并转移故障。故障转移包含如下多个操作：

        1，等待多个哨兵回复，选出可升级为master的slave;

        2，将slave升级为master，修改哨兵配置文件记录的结点信息；

        3，从节点从新master复制数据；

        1.2.2，哨兵配置后属性

sentinel config-epoch mymaster 0

        故障转移的版本管理，每次故障转移都需要唯一版本，防止哨兵间故障版本冲突。当哨兵执行故障转移时，将递增该版本号，并广播给其他哨兵。若哨兵间版本不一致，将使用最大版本号。

2，故障转移演示

        在当前一主两从+三哨兵架构下，演示master宕机，哨兵自动故障转移情景。上面可知当前主节点是 6379. 现在停掉6379服务，模拟生产宕机，如下图：

        查看6380和6381的 info replication

        同理，查看哨兵日志

        由上图可知， 主节点6379下线后，哨兵自动选举出6381作为主节点。

        注意：

        1，本机搭建案例，前面的配置IP均使用的事192...，后面哨兵选举时出现ping连接失败情况，后改为回环地址IP，则自动选举成功。

        2，哨兵机制仍然存在弊端：

        第一：哨兵机制可能丢失数据。

                情景一：主从结构的本质是主节点写，从节点读或单纯备份。当未触发master-->slave的数据传输或备份时，master宕机，则这部分数据将丢失；

                情景二：master掉线，slave被升级为新master，当旧master重新上线时，会清空自身数据，从新master复制一份全量数据，则旧master未同步数据也会丢失。

        第二：哨兵机制的写操作都在master单节点，当master宕机时，整个Redis服务都不可用。

        基于上述问题表明，哨兵机制更适合不需要数据分片（即数据量不大），且Redis依赖度不高的系统（即Redis宕机对系统影响不大）。对于数据量大或依赖度高的系统，Redis提供了集群架构方案，保留了哨兵架构的自主选举优点，也解决了单节点压力过大的问题，详见下章节。