生产环境下，为保证redis的高可用性，通常会搭建集群，redis集群的好处无需多说，提升单节点的读写性能从而整体提升并发效率，达到整体QPS的提升，同时，多个节点可以实现数据共享，在集群模式下，从节点会通过RDB不断复制主节点数据达到数据的准实时备份，从而保障数据的安全性；
既然是redis集群嘛，我们很容易联想到使用一台主节点，多个从节点，实际中也是这样操作的，上一节我们模拟了在同一台机器下实现两个节点的主备，为引出后面的问题，我们先在3个节点上搭建一主2从的集群，来看效果；
环境准备，centos6.5,3台虚拟机，对应的IP分别是:192.168.9.144,192.168.9.145,192.168.9.146,这里我使用的redis的版本是4.0.11,其他的版本也可以，自行选择，建议大于3.2，因为3.x之前的sentinal不太稳定
redis的安装过程不再演示，比较简单，这里规划的是:
1、主节点:192.168.9.146
2、从节点:192.168.9.144,192.168.9.145
首先来看主节点相关信息，这里将使用后台守护进程的方式启动redis，在redis的主目录下，我新建了一个redis-6666.conf的配置文件，以及redis-6666.log的启动日志文件，
redis-6666.conf的配置文件内容是:
配置文件比较简单，第一个参数设置为后台启动，第二个参数表示启动的端口号，
然后就可以启动主节点的redis了,使用配置文件的方式启动，
可以看到主节点的redis已经成功启动，接下来分别看两个从节点的配置，两个从节点的配置文件基本一样，只是端口号稍有不同，请看192.168.9.144的配置，
该节点也新增了两个配置文件，redis-6667.conf和redis-6667.log，
这里在配置文件的后面增加了2行，意思很容易理解，表示该节点是主节点192.168.9.146的从节点，而且端口也要对应上，同时，该节点只能读，
另外一个从节点的配置和上述基本相同，不再赘述，贴出来，
两个从节点配置完毕，分别启动，
看到如上信息，说明两个从节点已启动成功，端口号分别是6667和6668,接下来我们分别连接上各个节点的客户端查看一下分片信息，先看主节点，
可以看到，主节点下挂了2个从节点，从节点的IP，端口号等基本信息都反映出来了，再看从节点的信息，
同样从节点的信息也可以看出来，已经成功搭建1主2从的redis集群，我们可以在主节点设置一个key/value来验证，
看到这里，说明我们的redis集群已经可以成功使用，上述就是模拟了生产环境下如何搭建redis主备节点的过程，具体的优化配置可以在conf的配置文件中继续添加，此处为演示而省略了，比如还可以设置数据的备份策略，调整数据同步的时间等；
我们可以分析一下，这样的主从结构确实可以解决单节点吞吐量不够，而且数据存储与共享的问题，但是不要忘记，实际环境下是很复杂的，举例来说，加入主节点宕机了，这个时候为了快速启动redis我们会怎么办，当然只能手动切换，修改从节点的配置文件，然后再启动，但是这样的过程怎么来说都要耗费几分钟的时间，这是不能容忍的，尤其是在类似双11这样的大型电商促销活动的时候，会带来灾难性的后果，有没有一种可以较好的解决这个问题的办法呢？那就是采用redis的sentinel，即哨兵模式，通过哨兵模式去监控集群的节点信息，自动实现故障的失效转移，保证redis集群的高可用性；
听起来，哨兵模式是一种挺高大上的玩意，理解起来简单来说，哨兵的sentinel就是一个监控组件，把这个组件嵌入到各个redis节点对应的机器上，去实时监控各个节点数据的情况，从而达到“哨兵”的作用，关于哨兵的更深层次的解读，大家可以参考先关材料加深理解，下面演示具体的搭建过程，
同样使用上述3个节点，在各个节点的redis主目录下分别新增几个配置文件，先看主节点192.168.9.146,主节点新增，redis-7000.conf、redis-7000.log以及sentinel-26379.conf,
前两个为启动的配置文件，后面一个是该节点下的哨兵配置文件，
redis-7000.conf配置如下:
关于另外两个从节点的启动的配置文件基本上和上面的一致，只是端口号有所不同，这里直接贴出来从节点的配置文件，不再过多解释，
192.168.9.144的配置：
192.168.9.145的配置:
下面分别来看各个节点的sentinel.conf的配置文件:
主节点sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir "./"
#sentinel监控的IP 端口号 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor mymaster 192.168.132.128 7000 2
#20秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，60秒内没有完成，则认为转移失败
sentinel failover-timeout mymaster 600000
bind 0.0.0.0
从节点1,sentinel-26380.conf配置文件:
port 26380
daemonize yes
logfile "26380.log"
dir "./"
sentinel monitor mymaster 192.168.132.128 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 600000
bind 0.0.0.0
从节点1,sentinel-26381.conf配置文件:
port 26381
daemonize yes
logfile "26381.log"
dir "./"
sentinel monitor mymaster 192.168.132.128 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 600000
bind 0.0.0.0
其实搭建哨兵模式的集群，主要就是上述的这些配置，配置文件搞定了，只需要启动然后进行操作即可，下面分别来启动各个节点，首先启动各个节点的服务，通过配置文件的方式进行启动，
看到上述信息，表明我们的三个节点都已经成功启动，对外暴露的端口号分别是7000,7001,7002,
接下来启动sentinal ,重复上述的过程，只是启动的命令有所不同，
看到上述的信息，说明我们三个节点的哨兵配置文件也成功启动了，我们连接上sentinel的客户端，通过info来查看当前哨兵管理监控的信息，在主节点上可以看到如下信息，
方框中圈出来的信息，代表了集群节点的基本信息，master的IP、端口号，slave的数量，
再看其中一个从节点的sentinel信息，
接下来分别连接到各个节点的redis客户端，通过客户端也可以看到各自节点的基本信息，
从节点：
主节点：
下面在主节点上设置一个key/value,
主节点
从节点：
看到这里，说明集群已经可以成功使用，下面模拟一下主节点挂掉的情况，为演示效果，我们直接将144节点的redis关闭，然后看另外的两个节点是否还能继续使用，
关闭的命令是: ./src/redis-cli -p 7001，关闭之后我们重新连接sentinel可以看到如下信息，
sentinel已经通过重新投票，选举出来新的master，对应的IP是146所在的节点，那么我们到146所在的节点上去看，
可以看到，146的角色已经发生改变，变成了master，我们在146的节点上设置key/value，在145所在的节点上去看，
可以看出来，145所在的节点的主节点信息已经指向新的IP146节点，同样可以获取到新的主节点上的key/value，而且上述的过程的发生，对于使用者来说基本上感受不到，sentinel自动帮助我们完成了主备的切换和故障的转移，
大家还可以在此基础上继续模拟一下将刚刚挂掉的144节点重新开启，再在sentinel客户端使用info命令查看一下各个节点的信息，这里就不再继续演示了；
到此为止，演示了整个哨兵模式下redis三个节点的搭建和基本的流程使用，实际工作中，大家可以参考继续做优化，由于内容比较多，大家还需要仔细斟酌，一步步细致进行，比如我遇到了一个坑就是三个节点的信息配对了但是就是没有数据，就是因为节点的防火墙没有关闭，大家可以注意一下；
最后感谢各位童鞋的耐心观看！不足之处，敬请指正！