Redis为我们提供了哨兵，它就像一个为我们的Redis服务站岗的人，当主服务器发生异常时，他会通过投票的方式，将从服务节点升为主服务节点。当我们处理好主节点故障并重启时，原来挂掉的主节点，作为新的主节点的子节点。
为了在本机测试，首先我在6379，6380，6381节点上开启三个redis服务，6379做为master节点，6380和6381作为其从服务节点。关于主从的配置如果有疑问的话请看我的这篇文章https://www.cnblogs.com/tdws/p/5705782.html。
下面你需要再将redis文件夹机器内容复制出一份，我将其文件夹命名为Sentinel.
我们将其配置文件最后，增加如下配置信息。配置信息配置了哨兵端口5000，我们的redis客户端，比如C#的stackservice,stackExechange,可以从哨兵中读取当前集群情况，也就是说主挂后，我们客户端都可以获取到信息，并且从新的服务节点及端口中进行键值的操作。另外配置文件说到，主服务节点为6379，并且多个哨兵时，得到哨兵们的投票为1票时就认为主节点失联，可切换从节点为主。
down-after-milliseconds 指明尝试多少毫秒无反应，哨兵认为其失联。
parallel-sync指明当故障发生时，允许有多少个从节点，同时从新的主节点同步数据。这个配置意义在于，你这个值设置的越小，所有从节点同步时间也就越久，比如如下配置，每次只能同步一个，从节点越多，自然也就越久。那么这个值设置的大，或造成什么影响，这取决于我们的配置文件，我们可以配置在从同步主节点时，以旧的数据提供给客户端，在同步完成后，提供新数据，这样不会造成从节点同步期间不可用的情况。而然而，在同步完成后，需要删除旧的数据，加载新的数据，在这短暂的期间，还是会有从节点不可用的情况发生。
port 5000 sentinel monitor mymaster 127.0.0.1 6379 1 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1
下面就到了我们启动sentinel(哨兵)的时候了！
同样切换到Sentinel文件夹目录下，执行命令
这样一来，哨兵"观察站"启动了。
首先我们展示下正常情况，主从的复制以及读写情况。
上图主节点写入新键。下图在两个从节点读取数据。
接下来，我们看一下主节点挂掉之后，会发生什么。我将主节点服务关闭。
我们之前的只读从节点，现在已经升为可写的主节点了！