1.redis-3.2.100下载：
redis-3.2.100的32位下载：https://pan.baidu.com/s/107xVp6LGT24Fq3GUcAwjNw 提取码：7aqm
redis-3.2.100的64位下载：https://pan.baidu.com/s/1MsF2fzd9XYJP-vvV2P6wPQ 提取码：3uqh
根据自己系统的位数下载对应版本即可。
=====================================
哨兵模式主要针对于主从服务做的高可用机制。所以需要先配置好redis的主从节点。
关于redis的主从配置参考：https://www.cnblogs.com/super-chao/p/15138986.html
=====================================
2.配置哨兵服务并启动：
配置好主从后，配置哨兵模式。哨兵模式检测master是否宕机，如果宕机，将选举slave为新的master。
复制3个redis文件，如图所示：
在sentinel的文件夹下新建文件sentinel.conf和启动文件sentinel_1.bat：
sentinel.conf的内容为：
port 16479 # 主节点名称 IP 端口号 选举次数 sentinel monitor mymaster 127.0.0.1 6479 1 # 心跳检测，多长时间检测一次master是否挂了 sentinel down-after-milliseconds mymaster 5000 # 最多多少个节点 sentinel failover-timeout mymaster 15000
sentinel_1.bat的内容为：
title sentinel_16479 redis-server.exe sentinel.conf --sentinel
其他sentinel文件夹下重复以上操作，只是port要设置为自定义端口号且不冲突。我监测的mymaster是6479端口。sentinel_1.bat修改titile为对应的端口号，用于区分dos窗口。
分别启动三个sentinel哨兵服务，启动后如图，说明启动成功：
其他两个sentinel一样。
3.测试哨兵机制：
启动6479，64791,64792的redis服务。
64791，64792一样。
新打开一个cmd窗口，cmd到任意一个redis根目录下，执行命令redis-cli -p 6379.
执行info replication查看节点信息：
表明6479是master，64791和64792是slave。
ctrl+c退出，redis-cli -p 64791切换到64791，执行info replication：
表明64791是从节点，主节点是6479.
当我关闭master的dos窗口时，6479的服务会关闭，此时模拟宕机。查看在哨兵机制下，主节点宕机，从节点选举为master的过程。
哨兵服务窗口会打印选举master的日志：
此时64792变成了master：
64791的master变成了64792：
重启6479后，6479会变为从节点，它的master是64792：
64792变成了master，节点信息如下：
总结：
在哨兵模式监测下，会通过ping主节点，不断监测master是否宕机，如果master宕机，就会通过选举机制从从节点中选出master。
sentinel会改变每个redis服务的配置redis.windows.conf中的slaveof。
上例中原来的配置为6479无slaveof, 64791的slaveof是6479, 64792的slaveof是6479.
哨兵机制选举后，配置改变：6479的slaveof是64792, 64791的slaveof是64792, 64792的slaveof被删除。
以64791为例，查看64791的redis.windows.conf配置：
同时每个哨兵服务的sentinel.conf配置信息也被修改。
sentinel monitor mymaster 127.0.0.1 6479 1改变成了sentinel monitor mymaster 127.0.0.1 64792 1。
以6479_sentinel_1为例：
至此，哨兵机制配置和测试完成。
从上面可以看出哨兵机制的作用：
解决redis高可用问题。
主节点的高可用性。
注意：
先有主从同步，然后才有哨兵机制。
哨兵机制(心跳)。
哨兵和redis没有任何关系，是一个单独的应用程序。
心跳检测(ping的方式)，检测master是否正常，如果不正常，通过哨兵模式的选举机制，选举新的master。
不正常的服务重启后会变成slave。
