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

 回到目录