主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。 这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式 。
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是 哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
这里的哨兵有两个作用
然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
用文字描述一下 故障切换(failover) 的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover *** 作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为 客观下线 。这样对于客户端而言,一切都是透明的。
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
首先配置Redis的主从服务器,修改redisconf文件如下
上述内容主要是配置Redis服务器,从服务器比主服务器多一个slaveof的配置和密码。
配置3个哨兵,每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinelconf文件,copy一份进行修改
上述关闭了保护模式,便于测试。
有了上述的修改,我们可以进入Redis的安装目录的src目录,通过下面的命令启动服务器和哨兵
注意启动的顺序。 首先是主机(19216811128)的Redis服务进程,然后启动从机的服务进程,最后启动3个哨兵的服务进程。
上面是通过Jedis进行使用的,同样也可以使用Spring进行配置RedisTemplate使用。
sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后,会自己认为主机不可用。对于其他哨兵而言,并不是这样认为。哨兵会记录这个消息,当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时,就会发起一次投票,进行failover,此时哨兵会重写Redis的哨兵配置文件,以适应新场景的需要。
redis集群模式,丢失master主服务器是无法继续工作的,所以随时都需要一个master节点。但是服务器宕机是经常出现的事情,集群本身是无法完成故障转移的,所以需要一个第三方的解决方案,帮redis集群完成故障转移(选择主节点、通知从节点修改同步master地址,让原来的主节点成为从节点)。(1)首先sentinel也属于一种redis服务器,只不过启动时加载的配置文件不同。配置文件里包括了监控的主服务器列表(对,可以是多个主服务器,即就是多个集群)。
(2)sentinel通过配置文件中的主服务器IP:端口号,建立链接和订阅,就是一个双向的通道
(3)sentinel默认每10秒,向建立链接的主服务器,发送INFO命令;主服务器收到命令,返回主服务器信息。
可以看到,返回了主服务器的运行ID,重要的是:同步主服务器的从节点信息
(4)从步骤(3)中获取到的从节点信息,从节点的IP和端口。sentinel和从节点建立链接和订阅
(5)sentinel默认每10秒,向建立链接的从服务器,发送INFO命令,从服务器接收到命令后,返回从服务器信息
主要包括了从服务器对应的master节点的地址:端口号,偏移量
(6)sentinel与主服务器和从服务器建立了链接和订阅,可以向主从服务器发送命令,也可以接收主从服务器的广播
订阅命令:subscribe _sentinel_:hello
通道名:hello
sentinel对hello频道的订阅会一直持续到sentinel和服务器之间的链接断开为止
sentinel向服务器通道发送的消息,其他与该服务器建立订阅关系的sentinel也会收到订阅通知,sentinel自己也会收到自己发出的消息的订阅通知
(7)sentinel默认会每两秒一次,向所有建立链接和订阅的主从服务器,发送广播消息
命令:publish_sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"
可以看到主要包含
s_ip : sentinel自己 IP地址
s_port : sentinel自己端口号
s_runid : sentinel自己的运行ID
s_epoch : sentinel当前的配置纪元
m_name, m_ip, m_port, m_epoch : 当前监控服务器的名称(主或者从)、IP地址、端口号、当前配置纪元
这个消息,也会被其他订阅该通道的sentinel收到
sentinel在接收到订阅消息后(就是上文中自己与别的sentinel,publish的消息),首先过滤掉自己发,然后接收别人的消息,就能获取监听改主服务器的所有sentinel节点
(8)通过上一步,sentinel能够感知到其他监控主服务器的sentinel节点,然后和其他sentinel建立连接,最终,所有监视主服务器的sentinel节点组成了一个相关连接的网络!
sentinel会默认每1s向自己所建立连接的服务器发送PING命令,这些服务器包括(监视master的其他sentinel,master、salve服务器),根据收到的返回值,来确定目标服务器的状态
常见返回值:+PONG、-LOADING、-MASTERDOWN,含义在此处先不关注
判定条件:目标服务器在一定的时间内(配置文件字段:down-after-milliseconds的值),一直返回“失败”
对失败的定义:
(1)目标服务器没有在规定时间内返回(该时间可配置)
(2)目标服务器返回了上述三种返回值之外的值
确定一个目标服务器失败之后,会在sentinel自己的实例表中记录该实例的状态,用:
SRI_S_DOWN表示,S=subjective客观
注:一个master服务器会被多个sentinel监控,多个sentinel可能设置了不同的
down-after-milliseconds
和我们设想的一样,单一的sentinel并不能决定目标master服务器的生死存亡,会拿着自己实例表里的“客观”下线的服务器地址和端口,去向同样监控这台服务器的sentinel询问,看看“别人”这个服务器到底下线没? 当能够从别的sentinel那里询问到“足够数量”的已下线(客观下线或者主观下线)结果后,sentinel就可以判断目标服务器真的下线了,就可以执行故障转移了。
(1)sentinel发送命令is-master-down-by-addr
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
发送的目标:监控master服务器的其他sentinel
参数解析:ip、port=自己监控的master服务器的IP,端口,current_epoch=源sentinel当前的配置纪元,runid=源sentinel的唯一标识ID
(2)sentinel对命令is-master-dowm-by-addr的回复
1) <down_state> :下线的状态,0-未下线,1-已下线
2) <leader_runid> :当前sentinel的局部leader,为 “” 时表示没有leader
3) <leader_epoch> :当前sentinel的局部leader的配置纪元,当没有leader时,该项为0
(3)sentinel收到命令is-master-down-by-addr的回复后
sentinel收到足够数量(可配置)的“已下线”回复(即down_state=1),就会在自己的实例表里将对应的master服务器状态(flags)设置为 SRI_O_DOWN,O=Objective。
监控同一个master服务器的sentinel,对客观下线的条件可以不一致,即收到多少已下线回复才认定客观下线,可以不尽相同。
由于监控同一个master服务器的sentinel有很多,并不能决定是哪个sentinel去执行故障转移,所以需要多个sentinel进行选leader头结点。
具体步骤:
(1)sentinel通过向其他sentinel节点发送is-master-down-by-addr命令,已经可以判断当前master服务器是否客观下线
(2)已经判断master服务器客观下线的sentinel,再次向其他节点发送
is-master-down-by-addr命令,携带自己的runId和配置纪元
这里再复习一遍命令 :
sentinel is-master-down-by-addr <ip>,<port>,<cur_epoch>,<runid>
(3)目标sentinel收到源sentinel的 is-master…命令之后,执行以下判断
1>判断epoch和自己的纪元是否相等,不相等直接舍弃这条命令
2>判断自己的配置表里是否有局部leader,没有的话,将源sentinel的runid设置为自己的局部了leader
如果已经有了局部leader,那么会返回自己的局部leader的信息
3>对源sentinel的is-master-down-by-addr命令进行回复
示例:
源sentinel向目标sentinel发送命令,
SENTINEL is-master-down-by-addr 127001 8080 0 11522852334a
源sentinel收到命令的回复
1
11522852334a
0
表示有一个sentinel将自己成功设置成为leader(需要把返回的runid和自己的runid比对)
4>当过半的sentinel将自己成功设置为局部leader,标识选主成功,如果在一段时间内没有收到过半的成功数,那么会进行下一轮命令的发送,epoch递增+1
例如,共有10个sentinel监视同一个master服务器,其中一个sentinel必须收到10/2+1=6个及以上的成功数,才能认为自己成功当选leader
(1)筛选master节点的备胎(即就是哪些slave节点可以成为新的master)
选择master节点备胎就一个要求,数据尽量完整,状态尽量好
1>删除,客观下线或者主观下线的slave服务器
2>删除,在最近5s没有回复过头sentinel节点的INFO命令的slave服务器
剩下的slave服务器,根据优先级进行排序,遇到优先级一样的,再根据偏移量排序(目的是筛选出和master服务器数据较同步的slave服务器)。再遇到偏移量一样的,继续根据runid排序,找出runid最小的(没有什么依据,只是个排序),至此,可以作为master的slave服务器就筛选好了。
(2)slave服务器升级为master
头sentinel向步骤(1)中筛选出来的slave服务器发送slaveof_no_one,发送完该转移命令。之后,头sentinel每秒一次的频率向上述slave服务器发送INFO命令,观察INFO命令返回的role字段,看是否变为master,变为master表示成功升级为master服务器。
(3)修改原slave服务器列表的复制/同步目标
头sentinel向原slave服务器列表发送命令:
slave of 127001:8080,修改slave的复制目标
(4)修改已下线的master服务器为新master的slave节点
头sentinel保持对已下线master的监控,当已下线master重新上线(对PING命令有回复),就对他发送slave of 127001命令,让其成为slave。
至此,故障转移全部结束。1、下载源码,解压缩后编译源码。
$ wget >在windows系统下安装多个Redis实例。服务器装有一个Redis实例,随着项目的进行,需要安装多个实例才可以。直接安装是只会有6379端口,需要采用下面的方式来安装。本示例讲解的是:redis-246-setup-64-bitexe 和redis-2817 windows MSOpen。工具/原料
Redis安装文件
CMD命令提示符
方法/步骤
下载安装文件,选择稳定版本
点击安装exe文件,进行安装。选择好路径,一直到安装结束即可。
点击Service查看Redis服务是否正确的安装。Windows--》Servicemsc。默认的端口为6379。服务已启动。
使用客户端工具进行连接,出现如下画面即成功。
使用CMD工具,安装另一个Redis实例服务,端口为6369 需要提前建好6369端口使用的conf文件
如:C:\Users\Gray>E:\redis-2817\redis-serverexe --service-install E:\redis-2817\redis6369conf --service-name RedisServer6369 --port 6369
试验了几次都没有提示成功的信息,但是查看服务成功了,而且用客户端连接也成功了。
查看6369端口的redis服务
步骤阅读
7
使用客户端连接6369 redis服务,出现如下界面表示成功不会。Redis服务器挂掉,客户端尝试连接Redis数据库时就会失败,是因为Redis是一个内存型数据库,所有数据都保存在内存中,Redis服务器挂掉,则客户端无法访问这些数据,此时客户端尝试连接Redis数据库,就会收到连接超时或连接拒绝的错误消息。1、安装编译工具
2、安装tcl组件包(安装Redis需要tcl支持)
3、安装Redis
4、设置redis开机启动
5、设置redis配置文件参数
6、测试redis数据库
7、通过php程序连接redis数据库 #php必须先安装Redis扩展
至此,Linux下Redis服务器安装配置完成。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)