Redis高可用集群方案——哨兵

本篇文章版权归博客园和作者吴双本人共同所有，转载和爬虫请注明原文系列地址http://www.cnblogs.com/tdws/tag/NoSql/

集群方案三主三从 http://www.cnblogs.com/tdws/p/7710545.html

之前有篇文章，讲到了redis主从复制，读写分离。然而留下的问题是当主服务器挂了，我们就无法向客户端提供任何服务了呀，这样的方案，就不能称之为高可用方案。下面，提供一种Redis集群高可用方案，拙劣之处，欢迎指正和补充。

Redis为我们提供了哨兵，它就像一个为我们的Redis服务站岗的人，当主服务器发生异常时，他会通过投票的方式，将从服务节点升为主服务节点。当我们处理好主节点故障并重启时，原来挂掉的主节点，作为新的主节点的子节点。

为了在本机测试，首先我在6379，6380，6381节点上开启三个redis服务，6379做为master节点，6380和6381作为其从服务节点。关于主从的配置如果有疑问的话请看我的这篇文章http://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文件夹目录下，执行命令