Redis哨兵(sentinel)模式搭建

一、Sentinel介绍

之前骚了一波Redis的简介及应用场景,今天试了下他的哨兵模式;

Sentinel是Redis的高可用性(HA)解决方案,由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,

并在被监视的主服务器进行下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。

Redis提供的sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决
监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器,

并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。


二、Redis Sentinel搭建

测试采用2个哨兵,1个主redis,2个从redis。
复制5份redis.windows.conf文件并重命名如下(开发者可根据自己的开发习惯进行重命名):

master.6379.conf 配置:

port 6379
#设置连接密码
requirepass grs
#连接密码
masterauth grs

slave.6380.conf 配置:

port 6380
requirepass grs
masterauth grs
dbfilename dump6380.rdb
#配置master
slaveof 127.0.0.1 6379

slave.6381.conf 配置:

port 6381
requirepass grs
masterauth grs
dbfilename dump6381.rdb
#配置master
slaveof 127.0.0.1 6379

sentinel.63791.conf 配置(将原配置文件清空后添加如下内容)(另一个一样,只需要修改下端口):

port 63791
#主master,2个sentinel选举成功后才有效,这里的master-1是名称,在整合的时候需要一致,这里可以随便更改
sentinel monitor master-1 127.0.0.1 6379 2
#判断主master的挂机时间(毫秒),超时未返回正确信息后标记为sdown状态
sentinel down-after-milliseconds master-1 5000
#若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败。
sentinel failover-timeout master-1 18000
#身份认证
sentinel auth-pass master-1 grs
#选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步,这个数字越小,完成故障转移所需的时间就越长
sentinel parallel-syncs master-1 1

这里有三个问题需要注意
第一,若通过redis-cli -h 127.0.0.1 -p 6379连接,无需改变配置文件,配置文件默认配置为bind 127.0.0.1(只允许127.0.0.1连接访问)
若通过redis-cli -h 192.168.180.78 -p 6379连接,需改变配置文件,配置信息为bind 127.0.0.1 192.168.180.78(只允许127.0.0.1和192.168.180.78访问)或者将bind 127.0.0.1注释掉(允许所有远程访问)
第二,masterauth为所要连接的master服务器的requirepass,如果一个redis集群中有一个master服务器,两个slave服务器,当master服务器挂掉时,sentinel哨兵会随机选择一个slave服务器充当master服务器,鉴于这种机制,解决办法是将所有的主从服务器的requirepass和masterauth都设置为一样。
第三,sentinel monitor master-1 127.0.0.1 6379 2 行尾最后的一个2代表什么意思呢?我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,当sentinel集群式,解决这个问题的方法就变得很简单,只需要多个sentinel互相沟通来确认某个master是否真的死了,这个2代表,当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。(sentinel集群中各个sentinel也有互相通信,通过gossip协议)。
按如下循序依次启动服务
1、redis-server master.6379.conf

2、redis-server slave.6380.conf

3、redis-server slave.6381.conf

4、redis-server sentinel.63791.conf --sentinel(linux:redis-sentinel sentinel.63791.conf)

5、redis-server sentinel.63792.conf --sentinel(linux:redis-sentinel sentinel.63792.conf)

查看master状态:

查看slave状态:

查看sentinel状态:

验证redis sentinel的主从切换:
1、首先关闭主redis(6379)服务(shutdown)。
2、查看哨兵,发现端口号为6380的从服务变成了主服务,sentinel自动完成了故障切换。
3、启动刚才被shutdown的6379服务并查看,发现它变成了从服务。
 

到这 我搭建和演示就结束了

后续单机版 spring 整合使用慢慢玩吧,成功了再来

参考如下:

https://blog.csdn.net/liguangyan_neu/article/details/78027105

如果有不足和错误的地方还请各位大佬指点

谢谢!!!

2018-10-25 13:46:10

原文地址:https://www.cnblogs.com/-ccj/p/9849338.html