关于redis-sentinel出现的原因
Redis集群的主从模式有个最大的弊端，就是当主master挂了之前，它的slave从服务器无法提升为主，而在redis-sentinel出现之后，有效的解决了这个问题，它相当于是一个投票者或者哨兵，它时刻监视着redis集群的各个服务器，当主master挂了之后，它将进行投票进行新master的选举，一般地，我们会建立多个redis-sentinel服务器，它们都会进行主master的选举工作，当多个redis-sentinal都选择同一个主之后，这个主才有效！
关于之前的主从模式
对于内部的主从模式（master-slaves)主要实现了数据的读写分离，可以有效的提升服务器的吞吐量，但对于高可用上，表现不佳，因为当主挂了之后，从slave无法成为主，或者没有这种机制，相关主从环境搭建请像我的这篇文章
关于sentinel环境的搭建
1 下载redis3.2版
2 建立几个副本文件夹
3 对redis-window.conf的信息进行修改，主要有以下3点
sentinel monitor mymaster 127.0.0.1 6379 2 //当前的主master,2个sentinel选举成功后，才有效
sentinel down-after-milliseconds mymaster 60000 //判断主master挂机的时间（毫秒）
sentinel failover-timeout mymaster 180000 //失败的超时时间
sentinel parallel-syncs mymaster 1 //选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长
4 以sentinel模块支持redis-server
对于windows版本的redis，没有像linux环境里redis-sentinel进程，而可以使用redis-server来启动sentinal，我们只要添加这个参数即可，代码如下
5 查看redis-sentinel下的主从服务器
- SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。
- SENTINEL slaves ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。
- SENTINEL get-master-addr-by-name ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。
- SENTINEL reset ： 重置所有名字和给定模式 pattern 相匹配的主服务器。
- SENTINEL failover ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
连接指定的redis-sentinel服务器
显示当前的主master服务器
Redis-sentinel的实际意义
对于我们使用方来说，有了redis-sentinel就等于有了当前的redis-master，即我们的数据就知道向哪台服务器写入了（其它slave都是从master同步的数据），这对于使用客户端的开发人员来说，直接链接redis-sentinel的返回值即可，当然前提是你不要求横向扩展，不要求分片存储，当然，这对一个大型数据存储来说，是可笑的，我们当然需要扩展，对大数据当然要进行自动分片，所有我们需要为redis-sentinal再加一层统一的代理服务器，如Twemproxy，有了ＴＷ代理，我们在连接redis时，直接连接ＴＷ的地址即可，这会自动分片，并且自动向redis-sentinel并连接真实的redis-master服务器！
对于我们的Sentinel来说，我们只能对它进行一些简单的操作，如订阅服务，同时，它为我们开放了很多事件，供我们在外面调用
Sentinel模式下的几个事件
- +reset-master ：主服务器已被重置。
- +slave ：一个新的从服务器已经被 Sentinel 识别并关联。
- +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
- +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
- +slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。
- +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
- +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。
- -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
- +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
- +sdown ：给定的实例现在处于主观下线状态。
- -sdown ：给定的实例已经不再处于主观下线状态。
- +odown ：给定的实例现在处于客观下线状态。
- -odown ：给定的实例已经不再处于客观下线状态。
- +new-epoch ：当前的纪元（epoch）已经被更新。
- +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
- +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。
- +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
- no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
- selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。
- failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
- failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
- failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
- +switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
- +tilt ：进入 tilt 模式。
- -tilt ：退出 tilt 模式。
本文转自博客园张占岭（仓储大叔）的博客，原文链接：Redis集群~windows下搭建Sentinel环境及它对主从模式的实际意义，如需转载请自行联系原博主。
