Redis高可用之Sentinel哨兵模式

一、背景与简介

        Redis关于高可用与分布式有三个与之相关的运维部署模式。分别是主从复制master-slave模式、哨兵Sentinel模式以及集群Cluster模式。

        这三者都有各自的优缺点以及所应对的场景、对应的业务使用量与公司体量。

 1、主从master-slave模式

   【介绍】

            这种模式可以采用一主一从、一主多从、以及树形结构的嵌套复制结构都是支持的。

   【优点】

            1、配置以及运维相对简单，可以支持读写分离，master节点负责写操作、slave负责进行读操作，同时slave作为master节点数据的一个备份，避免由于master节点挂掉，整个服务不可用。

    【缺点】

           1、master节点发生故障时需要人工进行介入，增加运维成本。通知客户端修改master的IP地址与端口，让slave节点顶上来作为主节点。那么之前的slave节点变成了主节点，等之前的old-master节点恢复后，反过来作为之前slave节点的从节点。 即使你可以把这个故障切主的过程进行自动脚本化，但是怎么确保多个slave中选择哪个slave成为新的主节点以及各种异常情况都能hold得住?  自己写的这个脚本就会变得很复杂。

          2、切主暂且不说自动化脚本还能解决，但是你让业务方切换IP+端口这个事情万万是不能被接受的。用到这个Redis的地方太多了，你想改也改不过来，改了要发新配置代码，还有就是怕漏改。即使你使用Nacos等配置中心，也是一件让人头疼的事情

        基于以上的几点考虑，官方推出了哨兵Sentinel模式，将这个过程自动化。切换流程不需要我们自己编写脚本，哨兵模式会可靠地帮我们完成这个故障切换过程，同时客户端也无须改变任何IP端口，无感进行故障切换。

     【适应的公司体量】      小公司、创业公司或者业务量不是特别大的公司

2、哨兵Sentinel模式

    【介绍 】

             哨兵Sentinel模式其实是将master-slave主从模式故障切换从人工介入换成了自动化切换的过程，哨兵节点会高效、快速、可靠的从剩余的slave节点中选择出1个合适的节点作为新的master主节点，之后将剩余的slave节点切主到这个新的master节点。同时，客户端要获取master节点信息要通过连接sentinel来获取master的IP和端口，这样每次切主的过程，程序会自动完成，无感迁移。

     【优点】

            1、官方原生支持高可用方案，比第一种master-slave手动写切换脚本以及通知业务方更换IP+端口更加方便、可靠、稳定

     【缺点】

            1、虽然哨兵解决了高可用问题，但是无法解决高容量、高并发的需求。 因为一个哨兵始终只是维护master-slave的高可用而已，不能解决高并发、高容量问题。 这个后续的Cluster集群模式可以来解决。

             2、切主的过程，可能会存在客户端短时间内连接不上master的情况，这个时间取决于故障迁移恢复时间。因为master节点挂了，哨兵在做故障迁移没结束之前,哨兵存储的master的信息还是挂掉的IP+端口，自然客户端继续连接挂掉的主机IP+端口就无法进行正常数据读写。 

    【适应的公司体量】    稍微有点业务体量与规模的公司

3、集群Cluster模式

   【介绍】

            集群Cluster模式支持分布式部署，采用虚拟槽的设计思路，将存储的key进行CRC16($key)%16383的方式对数据进行分片存储和读取。 一共存在0-16383的slot虚拟槽位， 一个虚拟槽位slot理论上可以支持一个master+N个slave的主从架构模式。 那就是理论上可以支持16383个master+slave的主从架构模式， 这样的量就已经很牛逼了。  

          同时集群模式本身就支持高可用，一旦slot节点的master-slave主从结构的主节点挂了，那么会从它所属的slot的master-slave主从结构中进行重新切主操作。

          不过官方推荐整个Redis集群不超过1000个节点。 想想一下，就算是1000个，如果按照一台服务器16G内存的情况计算，如果一半的内存进行存储也就是8G，整个集群的容量高达80TB。 这种基本上除了一线互联网大厂能玩得转，我看其它公司也没这个运维能力以及需求量了。

    【优点】

           1、支持高容量、高并发访问量的需求，官方原生支持、可靠稳定

           2、同时支持高可用模式，自动切主，实现故障迁移。  虽然故障迁移期间，客户端也可能会出现无法正常访问Redis集群的情况，但是只会影响落到这个slot的这些key， 其它的key还是能正常访问的，具体还得按照实际情况计算，节点越多，单个slot故障影响越小,可能只存在20-30%无法访问，可以理解只是挂了部分。但是，哨兵模式切主过程中产生不可用的情况就不一样，哨兵模式是故障迁移期间整体100%都无法访问。

    【缺点】

          1、对公司运维团队要求很高，运维成本高、同时成本也会变高

   【适应的公司体量】  一线或者二线的互联网大厂

二、哨兵Sentinel-简单实验

1、主从配置是Sentinel、Cluster的基础

        例如存在A节点作为master节点，存在2个slave节点分别是A1、A2.

        那么在A1、A2分别执行

slaveof $master_ip $master_port

        即可完成A作为master节点,A1、A2作为其slave节点的一主两从的拓扑结构。

        这个过于简单就不再演示，今天重点做Sentinel哨兵的故障模拟和迁移实验

2、环境搭建与测试

1、环境介绍

        我们准备3个sentinel节点， 以及一个一主两从的结构。 让这个3个sentinel哨兵节点对整个一主两从进行监听与负责故障转移。

        docker-compose.yaml文件内容如下:

version: "3"
services:
  s1:
    image: redis:5.0
    hostname: s1
    volumes:
      - "./redis-sentinel-26379.conf:/data/redis-sentinel-26379.conf"
    entrypoint: [ "tail", "-f", "/dev/null" ]
  s2:
    image: redis:5.0
    hostname: s2
    volumes:
      - "./redis-sentinel-26379.conf:/data/redis-sentinel-26379.conf"
    entrypoint: [ "tail", "-f", "/dev/null" ]
  s3:
    image: redis:5.0
    hostname: s3
    volumes:
      - "./redis-sentinel-26379.conf:/data/redis-sentinel-26379.conf"
    entrypoint: [ "tail", "-f", "/dev/null" ]

  master:
    image: redis:5.0
    hostname: master
    entrypoint: ["tail", "-f", "/dev/null"]
  slave1:
    image: redis:5.0
    hostname: slave1
    entrypoint: ["tail", "-f", "/dev/null"]
  slave2:
    image: redis:5.0
    hostname: slave2
    entrypoint: ["tail", "-f", "/dev/null"]

2、Sentinel哨兵的配置文件

redis-sentinel-26379.conf:

port 26379
daemonize yes
logfile "26379.log"
dir /data/
sentinel monitor mymaster master 6379 2  #Sentinel监控集群别名mymaster，监控的master这个用的host别名,可以写IP形式: 192.168.32.7，  6379是端口， 2是指投票个数
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 180000

 3、首先启动1主2从结构

docker-compose up -d --build #启动所有容器


# master节点
docker-compose exec master bash #进入master容器
redis-server &> /dev/null &  #运行redis-server进入后台


# slave1节点
docker-compose exec slave1 bash #进入slave1容器
redis-server &> /dev/null &  #运行redis-server进入后台
redis-cli  #进入控制台
slaveof master 6379  #切主
info replication #查看主从复制情况


# slave2节点
docker-compose exec slave2 bash #进入slave2容器
redis-server &> /dev/null &  #运行redis-server进入后台
redis-cli  #进入控制台
slaveof master 6379  #切主
info replication #查看主从复制情况

  查看master节点的集群节点信息: info replication

可以看到存在2个slave节点，分别是192.168.32.5(slave1)、192.168.32.6(slave2)正常连接运行

4、依次启动s1、s2、s3的Sentinel节点

redis-sentinel redis-sentinel-26379.conf  #后台运行sentinel节点程序

5、通过Sentinel API命令查看当前的master信息

sentinel masters

 查询结果如下:

6、模拟master节点故障，将master容器进行docker-compose stop操作

再次进入s1 sentinel节点运行redis-cli,  执行sentinel masters指令查看当前master的信息:

此时可以看到，本来master是192.168.32.7是主节点，后来模拟故障将这个节点进行stop操作。此时故障迁移已经完成, 从192.168.32.5、192.168.32.6选择了192.168.32.5做为新的master节点.

同时我们进入192.168.32.5(slave1)查看当前info replication信息:

7、恢复刚才的master容器，此时slave1再运行info replication会多出从节点

从slave1节点运行info replication，此时可以看到192.168.32.7从一开始的主节点反过来变成了slave1的从节点, slave1已经变成了新的master主节点:

三、总结

        选择简单主从模式、哨兵模式、或者集群模式，可以根据自己公司的业务量以及运维团队规模进行评估，选择合适的方案。 高可用一直和成本成反比关系，想要高可用那么付出的成本要变高，无论是运维成本还是资金成本， 反之，如果降低成本，那么可用性就会降低。

        公司体量还很小，处于起步阶段，推荐简单主从模式基本上够用了，成本也不会很高。

        如果已经稍微上规模了，还是推荐使用哨兵模式，这样故障迁移的过程就会自动化，无须人工介入更加稳定。

        如果已经是发展到哨兵模式都无法满足业务需求了，再考虑使用Cluster集群模式，能够满足更高容量、高并发访问量的需求。

       上面的这些模式都是基于IDC自己运维的机房或者自行搭建的机房环境，如果上云，自己想追求高可用性和可靠性，但是又没那么多运维精力的话，可以直接买云厂商的Redis服务即可，付钱买服务即可。