1. 哨兵

1.1 ⼈⼯恢复主节点故障

        Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量 的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的， 于是Redis从2.8开始提供了RedisSentinel（哨兵）加个来解决这个问题。

        通过自动化的手段，来解决主节点挂了的问题。哨兵机制，是通过独立的进程来体现的和之前redis-server是不同的进程。redis-sentinel不负责存储数据，只是对其他的redis-server进程起到监控的效果。通常哨兵节点，也会搞一个集合（多个哨兵节点构成的），防止单个哨兵节点挂了。

        Redis 主节点故障后需要进⾏的操作

          程序如何恢复：

          1.先看看主节点还能不能抢救了，好不好抢救。

          2.如果主节点这边是啥原因挂的，不好定位；或者原因知道，但是短时间难以解决 ，就需要挑一个从节点，设置为新的主节点～

            a）把选中的从节点，通过slaveof no one，自立山头

           b）把其他的从节点，修改slaveof的主节点ip port，连上新的主节点

           c）告知客户端（修改客户端的配置），让客户端能够连接新的主节点，用来完成修改数据的操作。

        当之前的挂了的主节点，修好了之后，就可以作为一个新的从节点，挂到这组机器中。

1.2  哨兵⾃动恢复主节点故障 

        当主节点出现故障时，Redis Sentinel能⾃动完成故障发现和故障转移，并通知应⽤⽅，从⽽实现 真正的⾼可⽤。

        Redis Sentinel 是⼀个分布式架构，其中包含若⼲个Sentinel节点和Redis数据节点，每个 Sentinel 节点会对数据节点和其余Sentinel节点进⾏监控，当它发现节点不可达时，会对节点做下线表⽰。如果下线的是主节点，它还会和其他的Sentinel节点进⾏“协商”，当⼤多数Sentinel节点对 主节点不可达这个结论达成共识之后，它们会在内部“选举”出⼀个领导节点来完成⾃动故障转移的 ⼯作，同时将这个变化实时通知给Redis应⽤⽅。整个过程是完全⾃动的，不需要⼈⼯介⼊。整体的 架构如图所⽰。

        这⾥的分布式架构是指：Redis数据节点、Sentinel节点集合、客⼾端分布在多个物理节点 上。

        Redis Sentinel 架构

        如果是从节点挂了～～其实没关系～
        1、如果是主节点挂了，哨兵就要发挥作用了。
           此时，一个哨兵节点发现主节点挂了还不够，需要多个哨兵节点来共同认同这件事情，主要是为了防止出现误判。
        2、主节点确实是挂了，这些哨兵节点中，就会推举出一个leader，由这个leader负责从现有的从节点中，挑选一个作为新的主节点

        3、挑选出新的主节点之后，哨兵节点就会自动控制该被选中的节点，执行slaveof no one，并且控制其他从节点，修改 slaveof 到新的主节点上。
        4、哨兵节点会自动的通知客户端程序，告知新的主节点是谁，并且后续客户端再进行的写
操作，就会针对新的主节点进行操作了。

1.3 redis哨兵核心功能

         1.监控

         2.自动的故障转移

         3.通知

        注意，redis哨兵节点有一个也是可以的。

        1.如果哨兵节点只有一个，它自身也是容易出现问题，万一这个哨兵节点挂了，后续redis节点也挂了，就无法进行自动的恢复过程了。

        2.哨兵节点出现误判的概率也比较高，网络传数据是容易出现抖动或者延退或者丢包的，如果只有一个哨兵节点，出现上述问题之后，影响就比较大。

        基本的原则：在分布式系统中，应该避免使用“单点“，尽量冗余一点。

        哨兵节点，最好要搞奇数个，建议最少也应该是3个。

2.使用docker搭建环境

        docker的安装

        只有一个云服务器，就在一个云服务器上配置六个节点，来完成这里的环境搭建，使用docker可以有效解决上面环境搭建文件配置繁琐的问题。

        虚拟机，通过软件在一个电脑上模拟出另外的一些硬件（构造了另一个虚拟的电脑），虚 拟机这样的软件，就可以使用一个计算机，来模拟出多个电脑的情况～
          但是虚拟机有一个很大的问题：比较吃配置，这个事情对于咱们的云服务器来说，压力山大。docker可以认为是一个“轻量级”的虚拟机，起到了虚拟机这样的隔离环境的效果，但是又没有吃很多的硬件资源，即使是配置比较拉的云服务器，也能构造出好几个这样的虚拟的环境，docker也是现在后端开发这块非常流行的组件。

        1.安装docker和docker-compose                                  
        2.停止之前的redis服务器

        service redis-server stop

        3.使用docker获取到redis的镜像

      docker pull redis:5.0.9

         docker pull使用docker从中央仓库（默认就是从docker hub）来拉取镜像拉取到的镜像，里面包含一个精简的Linux操作系统，并且上面会安装redis.只要直接基于这个镜像创建一个容器跑起来，此时，redis服务器就搭建好了。

        基于docker来搭建redis哨兵环境了，使用docker-compose来进行容器编排。此处涉及到多个redis server，也有多个redis哨兵节点。每一个redis server或者每一个redis哨兵节点都是作为一个单独的容器了。

        通过一个配置文件，把具体要创建哪些容器，每个容器运行的各种参数，描述清楚。后续通过一个简单的命令，就能够批量的启动/停止这些容器。使用yml这样的格式来作为配置文件，spring也是使用yml来作为配置文件的。

3. 搭建redis数据节点

        1）创建三个容器，作为redis的数据节点（一个主两个从）   
        2）创建三个容器，作为redis的哨兵节点                
       其实也是可以用一个yml文件，直接启动6个容器，如果把这个6个容器同时启动，可能是哨兵先启动完成，数据节点后启动完成，哨兵可能就会先认为是数据节点挂了，虽然对于大局不影响，但是会影响到观察执行日志的过程～

        配置文件的名字docker-compose.yml是固定的。

下面的客户端连接的容器中的镜像redis服务器：

                                    

4. 搭建redis哨兵节点

        redis哨兵节点是单独的redis服务器进程。

        理解 sentinel monitor

         sentinel monitor 主节点名 主节点 ip 主节点端⼝ 法定票数

        • 主节点名,这个是哨兵内部⾃⼰起的名字.

         • 主节点ip,部署redis-master的设备ip.此处由于是使⽤docker,可以直接写docker的容器名,会 被⾃动DNS成对应的容器ip

         • 主节点端⼝,不解释.

        • 法定票数,哨兵需要判定主节点是否挂了.但是有的时候可能因为特殊情况,⽐如主节点仍然⼯作正 常,但是哨兵节点⾃⼰⽹络出问题了,⽆法访问到主节点了.此时就可能会使该哨兵节点认为主节点 下线,出现误判.使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法.需要多个哨兵都认为 主节点挂了,票数>=法定票数之后,才会真的认为主节点是挂了

        创建配置⽂件

后台方式启动docker：

查看docker运行日志：

        docker-compose logs

列出当前docker中的局域网

 

重新修改yml文件 vim docker-compose.yml

关闭之前开启的容器，重新开启，发现此处的配置。

        是否可以把六个容器，都写到同一个yml配置中，一次全都启动不就直接保证互通问题了嘛？

        如果使用这种方案，由于docker-compose启动容器的顺序不确定，就不能保证redis-server一定是在哨兵之前启动的！最终结果也能正确运行，但是执行的日志可能有变数 ，分成两组来启动，就可以保证上述顺序.  观察到的日志，比较可控的。

        重新打开哨兵节点的配置文件，发现被重写。

5. 哨兵存在的意义

        哨兵存在的意义，能够在redis主从结构出现问题的时候（比如主节点挂了），此时哨兵节点就能够自动的帮我们重新选出一个主节点，来代替之前挂了的节点，保证整个redis仍然是可用状态。
        手动把主节点给干掉，当主节点挂了之后，哨兵节点就开始工作了！如下：

        docker stop master-redis；

        查看日志：

         docker stop master-redis；在重新启动主节点。

        哨兵重新选取主节点的流程：

        1.主观下线

          哨兵节点通过心跳包，判定redis服务器是否正常工作，如果心跳包没有如约而至，就说明redis服务器挂了，此时还不能排除网络波动的影响，因此就只能是单方面认为这个redis节点挂了        

        2.客观下线

         多个哨兵都认为主节点挂了.（认为挂了的哨兵节点数目达到法定票数），哨兵们就认为这个主节点是客观下线

         3.要让多个哨兵节点，选出一个leader节点，由这个leader负责选一个从节点作为新的主节点

        4.此时leader选举完毕，leader就需要挑选一个从节点，作为新的主节点

       1）优先级：每个redis数据节点，都会在配置文件中有一个优先级的设置.slave-priority，优先级高的从节点，就会胜出       

        2) offset最大，就胜出。offset从节点从主节点这边同步数据的进度。数值越大，说明从节点的数据和主节点就越接近                                

     3）runid每个redis节点启动的时候随机生成的一串数字（大小全凭缘分了，此时，选谁都可以了，随便挑一个）
      把新的主节点指定好了之后，leader就会控制这个这个节点，执行slave no one，成为master，再控制其他节点执行slave of，让这些其他节点，以新的master作为主节点了。

        哨兵小结：

• 哨兵节点不能只有⼀个.否则哨兵节点挂了也会影响系统可⽤性.

• 哨兵节点最好是奇数个.⽅便选举leader,得票更容易超过半数.

• 哨兵节点不负责存储数据.仍然是redis主从节点负责存储.

• 哨兵+主从复制解决的问题是"提⾼可⽤性",不能解决"数据极端情况下写丢失"的问题.

• 哨兵+主从复制不能提⾼数据的存储容量（redis集群，解决存储容量问题的有效方案）.当我们需要存的数据接近或者超过机器的物理内存,这样 的结构就难以胜任了.