`
QING____
  • 浏览: 2250679 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

Redis Sentinel:集群Failover解决方案

 
阅读更多

   Redis sentinel(哨兵)模块已经被集成在redis2.4+的版本中,尽管目前不是release,不过可以尝试去使用和了解,事实上sentinel还是有点复杂的.
   sentinel主要功能就是为Redis M-S(master,slaves)集群提供了1)master存活检测 2)集群中M-S服务监控 3) 自动故障转移,M-S角色转换等能力,从一个方面说是提高了redis集群的可用性.

    一般情况下,最小M-S单元各有一个maste和slave组成,当master失效后,sentinel可以帮助我们自动将slave提升为master;有了sentinel组件,可以减少系统管理员的人工切换slave的操作过程.

    sentinel的一些设计思路和zookeeper非常类似,事实上,你可以不使用sentinel,而是自己开发一个监控redis的zk客户端也能够完成相应的设计要求.

 

一.环境部署

    准备3个redis服务,简单构建一个小的M-S环境(伪分布式,如果是全分布式,配置信息适度修改即可);它们各自的redis.conf配置项中,除了port不同外,要求其他的配置完全一样(包括aof/snap,memory,rename以及授权密码等);原因是基于sentinel做故障转移,所有的server运行机制都必须一样,它们只不过在运行时"角色"不同,而且它们的角色可能在故障时会被转换;slave在某些时刻也会成为master,尽管在一般情况下,slave的数据持久方式经常采取snapshot,而master为aof,不过基于sentinel之后,slave和master均要采取aof(通过bgsave,手动触发snapshot备份).

 

   1)  redis.conf:

 

##redis.conf
##redis-0,默认为master
port 6379
##授权密码,请各个配置保持一致
requirepass 012_345^678-90
masterauth 012_345^678-90
##暂且禁用指令重命名
##rename-command
##开启AOF,禁用snapshot
appendonly yes
save “”
##slaveof no one
slave-read-only yes

 

##redis.conf
##redis-1,通过启动参数配置为slave,配置文件保持独立
port 6479
slaveof 127.0.0.1 6379
##-----------其他配置和master保持一致-----------##

 

##redis.conf
##redis-2,通过启动参数配置为slave,配置文件保持独立
port 6579
slaveof 127.0.0.1 6379
##-----------其他配置和master保持一致-----------##

 

    2) sentinel.conf

    请首先在各个redis服务中sentinel.conf同目录下新建local-sentinel.conf,并将复制如下配置信息.

##redis-0
##sentinel实例之间的通讯端口
port 26379
##此指令最后一个参数为<quorum>,
##表示选举时至少有quorum个sentinel实例推选某redis,它才能成为master
sentinel monitor def_master 127.0.0.1 6379 2
sentinel auth-pass def_master 012_345^678-90
sentinel down-after-milliseconds def_master 30000
sentinel can-failover def_master yes
sentinel parallel-syncs def_master 1
sentinel failover-timeout def_master 900000
 
##redis-1
port 26479
##--------其他配置同上-------##
 
##redis-2
port 26579
##--------其他配置同上-------# 

    3) 启动与检测

   

##redis-0(默认为master)
> ./redis-server --include ../redis.conf
##启动sentinel组件
> ./redis-sentinel ../local-sentinel.conf
    按照上述指令,依次启动redis-0,redis-1,redis-2;在启动redis-1和redis-2的时候,你会发现在redis-0的sentinel控制台会输出"+sentinel ..."字样,表示有新的sentinel实例加入到监控.不过此处需要提醒,首次构建sentinel环境时,必须首先启动master机器.

 

    此后你可以使用任意一个"redis-cli"窗口,输入"INFO"命令,可以查看当前server的状态:

   

> ./redis-cli -h 127.0.0.1 -p 6379
##如下为打印信息摘要:
#Replication
role:master
connected_salves:2
slave0:127.0.0.1,6479,online
slave1:127.0.0.1.6579,online
    "INFO"指令将会打印完整的服务信息,包括集群,我们只需要关注"replication"部分,这部分信息将会告诉我们"当前server的角色"以及指向它的所有的slave信息.可以通过在任何一个slave上,使用"INFO"指令获得当前slave所指向的master信息.

 

    "INFO"指令不仅可以帮助我们获得集群的情况,当然sentinel组件也是使用"INFO"做同样的事情.

    当上述部署环境稳定后,我们直接关闭redis-0,在等待"down-after-milliseconds"秒之后(30秒),redis-0/redis-1/redis-2的sentinel窗口会立即打印"+sdown""+odown""+failover""+selected-slave""+promoted-slave""+slave-reconf"等等一系列指令,这些指令标明当master失效后,sentinel组件进行failover的过程.

    当环境再次稳定后,我们发现,redis-1被提升("promoted")为master,且redis-2也通过"slave-reconf"过程之后跟随了redis-1.

    如果此后想再次让redis-0加入集群,你需要首先通过"INFO"指令找到当前的masterip + port,并在启动指令中明确指明slaveof参数:

> ./redis-server --include ../redis.conf --slaveof 127.0.0.1 6479

    sentinel实例需要全程处于启动状态,如果只启动server而不启动相应的sentinel,仍然不能确保server能够正确的被监控和管理.

 

    核心过程

    A)启动master实例

    B)依次启动各个slaves实例,使用“--slaveof”参数。到此为止,一个默认的M-S拓扑结构已经构建完成,接下来我们使用sentinels监控集群状况。

    C)依次启动每个redis实例上的sentinel进程。(不需要启动所有redis对应的sentinel进程,但是最终启动的进程个数不得小于sentinel.conf文件中<quorum>个)。

    D)因为每个sentinel实例的配置文件中,都指定了初始master的地址和端口,所以它们可以监控master的状态。

    E)每个sentinel可以通过向master实例发送“INFO”指令(间歇性,以确保新的slaves加入集群),来获取此master所有的slaves信息。“INFO”指令是sentinels获取M-S拓扑状态的途径,每个sentinel都会与所有的redis实例建立连接,以便监控实例的存活情况。

    F)master上会有一个专门的topic用于保存sentinel的状态信息,每个sentinel启动后,都会向master的topic中发布自己的信息,那么其他sentinel将会收到消息;同时每个sentinel也订阅此topic,用于检测所有sentinels的状态变更。所有的sentinels将通过topic用于互相发现。同时一旦发现新的sentinel加入,其他sentinel则立即与其建立连接,便于此后的选举。

 

二. sentinel原理

    首先解释2个名词:SDOWN和ODOWN.

  • SDOWN:subjectively down,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
  • ODOWN:objectively down,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.

    SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN".

   

    1) SDOWN与ODOWN转换过程:

  • 每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒)
  • 在交互中,如果redis-server无法在"down-after-milliseconds"时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.
  • 如果2)中SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送"is-master-down-by-addr <ip> <port>"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果检测到master处于SDOWN状态的slave个数达到<quorum>,那么此时此sentinel实例将会认为master处于ODOWN.
  • 每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
  • 经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.

    2) Sentinel与slaves"自动发现"机制:

    在sentinel的配置文件中(local-sentinel.conf),都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送"PING"以及类似于"is-master-down-by-addr"指令集,可用用来检测其他sentinel实例的有效性以及"ODOWN"和"failover"过程中信息的交互.
    在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口:

 +sentinel sentinel 127.0.0.1:26579 127.0.0.1 26579 ....

    发布的主题名称为"__sentinel__:hello";同时sentinel实例也是"订阅"此主题,以获得其他sentinel实例的信息.由此可见,环境首次构建时,在默认master存活的情况下,所有的sentinel实例可以通过pub/sub即可获得所有的sentinel信息,此后每个sentinel实例即可以根据+sentinel信息中的"ip+port"和其他sentinel逐个建立tcp连接即可.不过需要提醒的是,每个sentinel实例均会间歇性(5秒)向"__sentinel__:hello"主题中发布自己的ip+port,目的就是让后续加入集群的sentinel实例也能或得到自己的信息.
    根据上文,我们知道在master有效的情况下,即可通过"INFO"指令获得当前master中已有的slave列表;此后任何slave加入集群,master都会向"主题中"发布"+slave 127.0.0.1:6579 ..",那么所有的sentinel也将立即获得slave信息,并和slave建立链接并通过PING检测其存活性.

    补充一下,每个sentinel实例都会保存其他sentinel实例的列表以及现存的master/slaves列表,各自的列表中不会有重复的信息(不可能出现多个tcp连接),对于sentinel将使用ip+port做唯一性标记,对于master/slaver将使用runid做唯一性标记,其中redis-server的runid在每次启动时都不同.

 

   3) Leader选举:

    其实在sentinels故障转移中,仍然需要一个“Leader”来调度整个过程:master的选举以及slave的重配置和同步。当集群中有多个sentinel实例时,如何选举其中一个sentinel为leader呢?

    在配置文件中“can-failover”“quorum”参数,以及“is-master-down-by-addr”指令配合来完成整个过程。

    A) “can-failover”用来表明当前sentinel是否可以参与“failover”过程,如果为“YES”则表明它将有能力参与“Leader”的选举,否则它将作为“Observer”,observer参与leader选举投票但不能被选举;

    B) “quorum”不仅用来控制master ODOWN状态确认,同时还用来选举leader时最小“赞同票”数;

    C) “is-master-down-by-addr”,在上文中以及提到,它可以用来检测“ip + port”的master是否已经处于SDOWN状态,不过此指令不仅能够获得master是否处于SDOWN,同时它还额外的返回当前sentinel本地“投票选举”的Leader信息(runid);

    每个sentinel实例都持有其他的sentinels信息,在Leader选举过程中(当为leader的sentinel实例失效时,有可能master server并没失效,注意分开理解),sentinel实例将从所有的sentinels集合中去除“can-failover = no”和状态为SDOWN的sentinels,在剩余的sentinels列表中按照runid按照“字典”顺序排序后,取出runid最小的sentinel实例,并将它“投票选举”为Leader,并在其他sentinel发送的“is-master-down-by-addr”指令时将推选的runid追加到响应中。每个sentinel实例都会检测“is-master-down-by-addr”的响应结果,如果“投票选举”的leader为自己,且状态正常的sentinels实例中,“赞同者”的自己的sentinel个数不小于(>=) 50% + 1,且不小与<quorum>,那么此sentinel就会认为选举成功且leader为自己。

    在sentinel.conf文件中,我们期望有足够多的sentinel实例配置“can-failover yes”,这样能够确保当leader失效时,能够选举某个sentinel为leader,以便进行failover。如果leader无法产生,比如较少的sentinels实例有效,那么failover过程将无法继续.

 

    4) failover过程:

    在Leader触发failover之前,首先wait数秒(随即0~5),以便让其他sentinel实例准备和调整(有可能多个leader??),如果一切正常,那么leader就需要开始将一个salve提升为master,此slave必须为状态良好(不能处于SDOWN/ODOWN状态)且权重值最低(redis.conf中)的,当master身份被确认后,开始failover

    A)“+failover-triggered”: Leader开始进行failover,此后紧跟着“+failover-state-wait-start”,wait数秒。

    B)“+failover-state-select-slave”: Leader开始查找合适的slave

    C)“+selected-slave”: 已经找到合适的slave

    D) “+failover-state-sen-slaveof-noone”: Leader向slave发送“slaveof no one”指令,此时slave已经完成角色转换,此slave即为master

    E) “+failover-state-wait-promotition”: 等待其他sentinel确认slave

    F)“+promoted-slave”:确认成功

    G)“+failover-state-reconf-slaves”: 开始对slaves进行reconfig操作。

    H)“+slave-reconf-sent”:向指定的slave发送“slaveof”指令,告知此slave跟随新的master

    I)“+slave-reconf-inprog”: 此slave正在执行slaveof + SYNC过程,如过slave收到“+slave-reconf-sent”之后将会执行slaveof操作。

    J)“+slave-reconf-done”: 此slave同步完成,此后leader可以继续下一个slave的reconfig操作。循环G)

    K)“+failover-end”: 故障转移结束

    L)“+switch-master”:故障转移成功后,各个sentinel实例开始监控新的master。

三.Sentinel.conf详解

 

##sentinel实例之间的通讯端口
##redis-0
port 26379
##sentinel需要监控的master信息:<mastername> <masterIP> <masterPort> <quorum>
##<quorum>应该小于集群中slave的个数,只有当至少<quorum>个sentinel实例提交"master失效"
##才会认为master为O_DWON("客观"失效)
sentinel monitor def_master 127.0.0.1 6379 2

sentinel auth-pass def_master 012_345^678-90

##master被当前sentinel实例认定为“失效”的间隔时间
##如果当前sentinel与master直接的通讯中,在指定时间内没有响应或者响应错误代码,那么
##当前sentinel就认为master失效(SDOWN,“主观”失效)
##<mastername> <millseconds>
##默认为30秒
sentinel down-after-milliseconds def_master 30000

##当前sentinel实例是否允许实施“failover”(故障转移)
##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover),
##全局中至少有一个为yes
sentinel can-failover def_master yes

##当新master产生时,同时进行“slaveof”到新master并进行“SYNC”的slave个数。
##默认为1,建议保持默认值
##在salve执行salveof与同步时,将会终止客户端请求。
##此值较大,意味着“集群”终止客户端请求的时间总和和较大。
##此值较小,意味着“集群”在故障转移期间,多个salve向客户端提供服务时仍然使用旧数据。
sentinel parallel-syncs def_master 1

##failover过期时间,当failover开始后,在此时间内仍然没有触发任何failover操作,
##当前sentinel将会认为此次failoer失败。
sentinel failover-timeout def_master 900000

##当failover时,可以指定一个“通知”脚本用来告知系统管理员,当前集群的情况。
##脚本被允许执行的最大时间为60秒,如果超时,脚本将会被终止(KILL)
##脚本执行的结果:
## 1	-> 稍后重试,最大重试次数为10; 
## 2	-> 执行结束,无需重试
##sentinel notification-script mymaster /var/redis/notify.sh

##failover之后重配置客户端,执行脚本时会传递大量参数,请参考相关文档
# sentinel client-reconfig-script <master-name> <script-path>
    更详细信息,请参考src/sentinel.c源码 .配置文件加载过程参见方法:sentinelHandlerConfiguration(..)

四、Jedis客户端与Setinel

Set<String> sentinels = new HashSet<String>(16);
sentinels.add("127.0.0.1:26379");//集群中所有sentinels的地址
sentinels.add("127.0.0.1:26479");
sentinels.add("127.0.0.1:26579");
GenericObjectPoolConfig config = new GenericObjectPoolConfig();
config.setMaxTotal(32);
//setinel客户端提供了master自动发现功能
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool("def_master",sentinels,config,"012_345^678-90");
Jedis jedis = jedisSentinelPool.getResource();
try{
    //
	jedis.set("key","value");
} finally {
	jedisSentinelPool.returnResource(jedis);
}
jedisSentinelPool.close();

 

    JedisSentinelPool将遍历sentinels列表,并尝试与每个sentinel建立连接直到成功为止;如果建立连接成功,就向此sentinel发送“get-master-addr-by-name”指令,获取master的位置,此后将建立与master的连接。此后JedisSentinelPool还会启动一个监测线程,用于监测master的存活情况,如果master角色迁移,则重新获取新的master地址,并重新初始化连接池。注意JedisSentinelPool并没有提供“M-S”下读写分离的设计,即读写操作均在master上发生。不过很遗憾,我觉得还是需要一种客户端解决方案,能够实现读写分离。 

 

五、归结

    1、sentinel进程,也是一个redis进程。

    2、集群中需要至少三个sentinal进程,才能有效的决策master的状态。 

    3、sentinels之间,需要选举出leader,来监管failover的过程和结果。

    4、sentinels之间会互相建立连接,通过特殊的端口通讯;sentinels与redis实例也会建立连接,用于检查redis实例的存活性。

    5、sentinels互相发现,是通过在master上特殊的topic中发布各自的address信息来实现的,每个sentinel都会订阅此topic,用于发现其他sentinel的加入或者离开。

    6、sentinel实例,都会间歇性的向topic中报告自己的状态,以便其他sentinel发现自己、检测自己的活性等。

    7、当sentinel发现master不可用时,将向topic中发布信息,当足够的sentinel都检测到master不可用时,leader将会判定此master下线的事实,并进行failover。

    7、在master失效后,sentinel的leader负责failover,将根据slaves的数据新鲜程度、权重、server ID等做决策,选举出新的master,即选举数据最新的slave作为master。

分享到:
评论
7 楼 ReadMoon 2015-08-13  
楼主你好,碰到这么个问题,当shutdown master之后,sentinel可以检测到master失效了,并且将一个slave切换成master,但是这个时候,通过sentinel查看master的slaves,发现slaves当中有原来的那个master,但是这个master已经被shutdown了啊,我觉得只有再次启动原来的那个master他才算是一个slave吧,而且最关键的是,我发现sentinel切换master之后还会发布+slave的消息,增加的就是那个停掉的master,这样在生产环境,客户端就无法区分这个+slave到底是切换master发出的还是真的添加了一个slave实例,请问有什么好的解决方案。

补充一下,我们是打算做一个web系统,可以实时查看当前redis的拓扑关系图,初始化的时候,从sentinel获取master和slave,并且订阅switch-master和+slave,结果测试的时候发现了这个问题
6 楼 chainhou 2013-10-12  
QING____ 写道
chainhou 写道
,楼主你好,想问下,你有了解Redis的自动扩容方式吗?目前我了解到的基本都是通过一致性hash将数据保存到不同的Redis实例,但是当数据量增大后,如果增加节点,还需要修改Client的hash方式,以便写到新的库中。有没有其它方式呢  谢谢

很抱歉,这么久才回复你.
redis以及其他类似的网络IO server,实现绝对意义上的自动扩容(server端)和自动探测与rebalance,是很难的,同时也有一些风险.

我们现在的做法也比较土:
1) 有个web portal系统,当一个redis实例部署好之后,就是web系统上输入它的IP地址和探测脚本(脚本用来检测redis的内存负载情况,存活情况).
2) 录入之后可以将此redis"上线/下线",即将redis信息同步到zookeeper中(俗称configserver);
3) 所有redis-client端,都接入configserver,获取可用的redis列表;并初始化redis-client.
4) redis-client有一个额外的线程用来与configserver保持通讯,实时的跟踪redis列表的变更.
5) 如果redis列表变更,将导致redis-client端重新调整,主要是重建"一致性hash表".
6) 重建"一致性hash表"的过程,不需要调整代码或者重启服务,这个和hash的设计方式有些关系.


简单的来说,你可以使用任何方式(db,或者JMS订阅)来获取redis集群节点的变更数据即可..对于"客户端一致性hash表"的设计,也需要有些技巧,最好不要因为一个节点的join或者remove,导致大面积缓存的命中失败..
希望对你有所帮助,谢谢!

多谢多谢,最近在做redis和cassandra的预研,预研后确定到底要用哪个,我们的场景主要用来缓存用户会话,做分布式缓存来用,和应用服务器搭配,实现高可用。看了你的回复收获很多,祝工作顺利。
5 楼 QING____ 2013-10-11  
chainhou 写道
,楼主你好,想问下,你有了解Redis的自动扩容方式吗?目前我了解到的基本都是通过一致性hash将数据保存到不同的Redis实例,但是当数据量增大后,如果增加节点,还需要修改Client的hash方式,以便写到新的库中。有没有其它方式呢  谢谢

很抱歉,这么久才回复你.
redis以及其他类似的网络IO server,实现绝对意义上的自动扩容(server端)和自动探测与rebalance,是很难的,同时也有一些风险.

我们现在的做法也比较土:
1) 有个web portal系统,当一个redis实例部署好之后,就是web系统上输入它的IP地址和探测脚本(脚本用来检测redis的内存负载情况,存活情况).
2) 录入之后可以将此redis"上线/下线",即将redis信息同步到zookeeper中(俗称configserver);
3) 所有redis-client端,都接入configserver,获取可用的redis列表;并初始化redis-client.
4) redis-client有一个额外的线程用来与configserver保持通讯,实时的跟踪redis列表的变更.
5) 如果redis列表变更,将导致redis-client端重新调整,主要是重建"一致性hash表".
6) 重建"一致性hash表"的过程,不需要调整代码或者重启服务,这个和hash的设计方式有些关系.


简单的来说,你可以使用任何方式(db,或者JMS订阅)来获取redis集群节点的变更数据即可..对于"客户端一致性hash表"的设计,也需要有些技巧,最好不要因为一个节点的join或者remove,导致大面积缓存的命中失败..
希望对你有所帮助,谢谢!
4 楼 chainhou 2013-09-30  
,楼主你好,想问下,你有了解Redis的自动扩容方式吗?目前我了解到的基本都是通过一致性hash将数据保存到不同的Redis实例,但是当数据量增大后,如果增加节点,还需要修改Client的hash方式,以便写到新的库中。有没有其它方式呢  谢谢
3 楼 gxz1989611 2013-09-16  
QING____ 写道
gxz1989611 写道
PO主,我有个问题问下,sentinel failover之后,redis replication的ip和端口理论上都发生了变化,和redis连接的客户端也要重新更改连接配置?


1) sentinel failover所解决的问题,就是集群中master实效后自动分配master角色,用来接收client端的write操作;最终使整个集群处于稳定状态.如果没有sentinel,master实效,需要系统管理员人工干预"角色重分配".

2) sentinal failover之后,必然意味着,master的IP + port发生改变.如果redis-client通过TCP直连的方式操作redis,有可能旧的master已经失效或者成为了slave,那么此后此client链接上所触发的write操作,有可能不会被接受(当readonlye=true时).目前而言,redis的slave尚不具备write操作自动转发到master的能力.(尽管其他DB已经具备类似功能).

3) 有些redis-client已经提供了master自动发现的能力,但是更加高效的"读写分离"层设计,我不太确定,目前是否已经有可用的解决方案..

4) 你可以在redis-client端补充一个"INFO"指令的探测方法,当client端抛出"not master"异常之后,通过"INFO"指令重新获取master信息,然后重建链接即可..

5) 或者重写sentinal代码,在新的master出现之后,将信息注册到zookeeper上;redis-client端只需要关注zookeeper中的信息即可..

6) 请关注redis cluster相关模块---不久的将来才会有..

这两天也看了tweet的twemproxy,感觉这种代理分片的思路也不错,关键是tweet在大规模使用。
2 楼 QING____ 2013-09-13  
gxz1989611 写道
PO主,我有个问题问下,sentinel failover之后,redis replication的ip和端口理论上都发生了变化,和redis连接的客户端也要重新更改连接配置?


1) sentinel failover所解决的问题,就是集群中master实效后自动分配master角色,用来接收client端的write操作;最终使整个集群处于稳定状态.如果没有sentinel,master实效,需要系统管理员人工干预"角色重分配".

2) sentinal failover之后,必然意味着,master的IP + port发生改变.如果redis-client通过TCP直连的方式操作redis,有可能旧的master已经失效或者成为了slave,那么此后此client链接上所触发的write操作,有可能不会被接受(当readonlye=true时).目前而言,redis的slave尚不具备write操作自动转发到master的能力.(尽管其他DB已经具备类似功能).

3) 有些redis-client已经提供了master自动发现的能力,但是更加高效的"读写分离"层设计,我不太确定,目前是否已经有可用的解决方案..

4) 你可以在redis-client端补充一个"INFO"指令的探测方法,当client端抛出"not master"异常之后,通过"INFO"指令重新获取master信息,然后重建链接即可..

5) 或者重写sentinal代码,在新的master出现之后,将信息注册到zookeeper上;redis-client端只需要关注zookeeper中的信息即可..

6) 请关注redis cluster相关模块---不久的将来才会有..
1 楼 gxz1989611 2013-09-13  
PO主,我有个问题问下,sentinel failover之后,redis replication的ip和端口理论上都发生了变化,和redis连接的客户端也要重新更改连接配置?

相关推荐

    第四十六章:Redis sentinel哨兵集群1

    Redis Sentinel是一种高可用性解决方案,它是Redis官方提供的一种分布式系统,专门用于监控Redis集群中的Master主服务器状态。在Master出现故障时,Sentinel能够自动进行故障转移,将健康的Slave提升为新的Master,...

    Redis Sentinel

    Redis Sentinel是Redis数据库系统中的高可用性解决方案,用于监控、通知和自动故障转移。在Windows环境下搭建Redis Sentinel集群,你需要了解以下几个关键知识点: 1. **Redis Sentinel系统**:Redis Sentinel是一...

    redis-sentinel-集群.7z

    Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务: 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。 提醒(Notification): 当被监控的某个...

    redis哨兵模式搭建.rar

    Redis Sentinel是Redis的一个高可用性解决方案,用于监控、故障检测以及自动故障恢复主从集群。在Redis中, Sentinel系统可以确保即使在主服务器宕机的情况下,数据仍然能够被正确访问,通过将流量重新路由到备用...

    Redis中Sentinel高可用解决方案.docx

    ### Redis Sentinel 高可用解决方案详解 #### 一、概述 Redis Sentinel 是一种高可用解决方案,旨在提高 Redis 服务的稳定性和可靠性。它通过一组 Sentinel 实例来监测 Redis 主服务器及从服务器的状态,当主...

    Redis Sentinel主从高可用方案1

    总结来说,Redis Sentinel 提供了一种强大的高可用性解决方案,通过监控、通知和自动故障迁移功能,确保 Redis 集群在主节点故障时仍能保持服务,同时通过 Jedis SentinelPool 支持,使得客户端能轻松适应这种变化,...

    redis+sentinel的配置

    Redis Sentinel 是一个高可用性解决方案,用于管理 Redis 集群,确保主从复制的稳定性和故障转移的自动化。在本文中,我们将深入探讨 Redis Sentinel 的配置,了解如何设置和利用它来提升 Redis 服务的可靠性。 ...

    redis哨兵集群安装文件,配置文件

    Redis Sentinel集群是Redis高可用性解决方案的关键组成部分,它提供了监控、故障检测以及主从节点自动故障转移的功能。在这个压缩包中,包含的可能是Redis的安装文件和Sentinel的配置文件,这些都是搭建和管理Redis ...

    redis window版本哨兵

    Redis Sentinel是Redis数据库系统中的高可用性解决方案,它主要用于监控、故障检测以及在主从架构中自动进行故障转移。在Windows环境下,Redis Sentinel的配置和使用可能会与Linux有所不同,但核心功能保持一致。...

    Redis哨兵模式(Redis-Sentinel)实例配置.rar

    Redis Sentinel,也称为Redis哨兵模式,是Redis官方提供的一个高可用性解决方案,用于监控、故障检测以及在主从架构中自动完成故障转移。在这个实例配置中,我们将深入理解哨兵系统的工作原理,并学习如何设置和操作...

    redis7.0.0集群相关安装包

    在集群环境中,Redis 集群可以提供高可用性和水平扩展性,确保服务在单个节点故障时仍能正常运行,并通过分片技术来分散负载。在这个“redis7.0.0集群相关安装包”中,包含了构建和管理Redis 7.0.0集群所需的基本...

    深入浅出Redis-redis哨兵集群.docx

    Redis Sentinel 是Redis的一个重要组件,它提供了高可用性(HA)解决方案,确保在主Redis服务器故障时能够自动切换到备份节点,从而保持服务的连续性。本文将深入探讨Redis Sentinel的集群原理、工作流程以及源码...

    redis-sentinel.tar.gz

    Redis Sentinel 是一个重要的组件,它是 Redis 高可用性(HA)解决方案的关键部分。这个压缩包“redis-sentinel.tar.gz”包含了一组脚本,旨在帮助用户设置和管理 Redis Sentinel 系统,确保数据的持久性和服务的...

    Redis哨兵模式(sentinel)学习总结及部署记录(主从复制、读写分离、主从切换)

    Redis Sentinel,或者称为哨兵系统,是Redis提供的一种高可用性解决方案,用于监控、故障检测以及自动故障恢复。哨兵模式旨在确保Redis集群在主服务器出现故障时能够自动切换到从服务器,保持服务的连续性。 一、...

    Redis Sentinel实现高可用配置的详细步骤

    Redis Sentinel 是一个高可用性(HA)解决方案,用于监控、故障检测和自动故障恢复Redis主节点。通过使用Sentinel系统,你可以确保即使在主节点出现故障时,数据仍然能够被可靠地访问,从而保证服务的连续性和数据的...

    sentinel 集群配置文件

    以下是一些关于Redis Sentinel集群配置文件的关键知识点: 1. **基本配置项**: - `port`: Sentinel监听的端口号,每个Sentinel实例都有自己的监听端口。 - `bind`: 指定Sentinel监听的IP地址,可以是多个。 - `...

    Redis哨兵集群配置

    Redis哨兵集群是一种高可用性解决方案,用于监控和管理Redis主从复制结构。哨兵系统通过监控、故障检测和自动故障转移确保了集群的稳定运行。以下是对哨兵集群配置的详细步骤和相关知识点的解释: 1. **哨兵安装与...

    redis-64.3.0.503-sentinel.zip

    Redis Sentinel 是一个重要的组件,它是 Redis 高可用性(HA)解决方案的关键部分。在这个名为 "redis-64.3.0.503-sentinel.zip" 的压缩包中,包含的是 Redis Sentinel 版本 64.3.0.503 的二进制文件和其他相关资源...

Global site tag (gtag.js) - Google Analytics