Redis集群~windows下搭建Sentinel环境及它对主从模式的实际意义

 回到目录

关于redis-sentinel出现的缘由

Redis集群的主从模式有个最大的弊端，就是当主master挂了以前，它的slave从服务器没法提高为主，而在redis-sentinel出现以后，有效的解决了这个问题，它至关因而一个投票者或者哨兵，它时刻监视着redis集群的各个服务器，当主master挂了以后，它将进行投票进行新master的选举，通常地，咱们会创建多个redis-sentinel服务器，它们都会进行主master的选举工做，当多个redis-sentinal都选择同一个主以后，这个主才有效！

关于以前的主从模式

对于内部的主从模式（master-slaves)主要实现了数据的读写分离，能够有效的提高服务器的吞吐量，但对于高可用上，表现不佳，由于当主挂了以后，从slave没法成为主，或者没有这种机制，相关主从环境搭建请像个人这篇文章

《Redis学习笔记~conf自主集群模式》

关于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 模式。

 回到目录