redis哨兵机制

1)哨兵机制本质上是通过独立的进程来体现的，和之前的redis-server进程是完全不同的进程，redis-sentinel不负责存储数据，只是针对于其他的redis-server进程起到监控的效果，但是通常来说哨兵节点，也会搞一个集合，这本身是由多个哨兵节点构成的

2)主节点挂了，把选中的从节点，通过slave of no one自立山头，把其他的从节点，修改slave of 主节点的IP port连上新的主节点，告知客户端，修改客户端的配置，完成修改数据的操作，当之前挂了的的主节点修好了以后，就可以作为一个新的主节点挂到这组机器中，但是修复的过程中，至少需要半个小时，整个redis不能写？

1.监控:监控主节点和从节点的工作状态，及时发现某一个节点是不是挂了 

2.自动的故障转移:对于主节点如果要是挂了，就可以自动地挑选出一个主节点，保证整个redis主从还是可以进行读和写，全程不需要人工来干预

3.通知:自动通知客户端

 

从上面来看，单独的redis sentinel进程提供了多个，并且这三个哨兵进程就会监控现有的redis master和slave，这些进程之间，会建立TCP长连接，通过这样的长连接就可以定期发送心跳包，借助上述的监控机制，就可以发现某一个主机是否挂了，如果是从节点挂了，没有关系，但是如果是主节点挂了，哨兵就需要发挥作用了

1)此时如果是一个哨兵节点发现主节点挂了，还不够，需要多个哨兵节点来共同确认这件事情，主要是为了防止误判

2)主节点确实是挂了，那么在这些哨兵节点中，就会推选出一个哨兵leader，由这个leader来负责从现有的从节点中，选取一个作为新的主节点

3)挑选出新的主节点以后，哨兵节点就会自动控制被选中的从节点，执行slave of no one命令，并且控制器其他从节点修改slave of到新的主节点上面

4)哨兵机制会自动地通知客户端程序，告知新的主节点是谁，并且后续客户端再来执行写操作，就会针对于新的主节点进行操作了

其实redis哨兵节点只有一个也是可以的

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

2)出现误判的概率也是比较高的，毕竟网络传输数据时容易出现抖动或者是延迟或者是持续性丢包的，如果只有一个哨兵节点，出现上述问题后，影响就比较大，所以说在分布式系统中，应该避免使用单点

因为分布式一方面是为了高可用，不能说一个服务器出现了问题，影响到整体的使用，效率也就是为了引入更多的硬件资源，如果全部放到一个机器上面了，那么两个条件都没有达成 

1.安装docker和docker compose，docker compose管理多个容器

2.停止redis服务器:后续使用docker启动redis的时候，在docker里面可能占用宿主机的端口号

3.使用docker获取到redis的镜像，在docker中，镜像和容器相当于是可执行程序和进程之间的关系，镜像可以自己构建，也可以直接拿别人已经构建好的，dockerhup包含了很多其他大佬们构建好的镜像，也提供了官方提供好的镜像，直接拖下来就可以使用

4.docker pull redis:5.0.9，git pull是使用git从中央仓库拉取代码，docker pull是使用docker从中央仓库来拉取镜像，默认是从dockerhup，本身拉取到的镜像，里面就包含一个精简的linux操作系统，并且上面会安装redis

5.拉取到的镜像，里面包含一个精简的linux操作系统，并且在上面会安装redis，只要直接基于这个镜像创建出一个容器跑起来，此时redis服务器就直接搭好了；

6.基于docker搭建redis哨兵模式