专栏名称: java那些事
分享java开发中常用的技术,分享软件开发中各种新技术的应用方法。每天推送java技术相关或者互联网相关文章。关注“java那些事”,让自己做一个潮流的java技术人!《java程序员由笨鸟到菜鸟》系列文章火热更新中。
目录
相关文章推荐
51好读  ›  专栏  ›  java那些事

Redis单例、主从模式、sentinel以及集群的配置方式及优缺点对比

java那些事  · 公众号  · Java  · 2019-04-05 16:00

正文

请到「今天看啥」查看全文


.0 .1 :6379 > get msg
( nil )




127 .0 .0 .1 :6380 > get msg
( nil )




127 .0 .0 .1 :6381 > get msg
( nil )


可以看到,在三个redis实例中都不存在键为msg的数据,现在我们在主机6379上设置一个键为msg的数据,如下所示:


127 .0 .0 .1 :6379 > set msg " hello "
OK


可以看到设置成功了,此时我们在6380和6381的实例上执行 get msg 的命令,如下所示:


127 .0 .0 .1 :6380 > get msg
" hello "




127 .0 .0 .1 :6381 > get msg
" hello "


可以看到,虽然我们只是在6379的实例上设置了msg这条数据,但是在6380和6381的实例上也存有了相应的数据,说明我们成功配置了redis的主从模式。另外,如果不在配置文件中指定主从节点的关系,也可以在启动相关redis实例之后使用 slaveof 命令来指定当前节点称为某个节点的从节点,如:


127 .0 .0 .1 :6380 > slaveof 127 .0 .0 .1 6379


3.redis中sentinel配置

redis主从模式解决了数据备份和单例可能存在的性能问题,但是其也引入了新的问题。由于主从模式配置了三个redis实例,并且每个实例都使用不同的ip(如果在不同的机器上)和端口号,根据前面所述,主从模式下可以将读写操作分配给不同的实例进行从而达到提高系统吞吐量的目的,但也正是因为这种方式造成了使用上的不便,因为每个客户端连接redis实例的时候都是指定了ip和端口号的,如果所连接的redis实例因为故障下线了,而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址,因而需要手动更改客户端配置重新连接。另外,主从模式下,如果主节点由于故障下线了,那么从节点因为没有主节点而同步中断,因而需要人工进行故障转移工作。

为了解决这两个问题,在2.8版本之后redis正式提供了 sentinel (哨兵)架构。关于 sentinel ,这里需要说明几个概念:

每个 sentinel 节点其实就是一个redis实例,与主从节点不同的是 sentinel 节点作用是用于监控redis数据节点的,而 sentinel 节点集合则表示监控一组主从redis实例多个 sentinel 监控节点的集合,比如有主节点 master 和从节点 slave-1 slave-2 ,为了监控这三个主从节点,这里配置N个 sentinel 节点 sentinel-1 sentinel-2 ... sentinel-N 。如下图是 sentinel 监控主从节点的示例图:

从图中可以看出,对于一组主从节点, sentinel 只是在其外部额外添加的一组用于监控作用的redis实例。在主从节点和 sentinel 节点集合配置好之后, sentinel 节点之间会相互发送消息,以检测其余 sentinel 节点是否正常工作,并且 sentinel 节点也会向主从节点发送消息,以检测监控的主从节点是否正常工作。

前面讲到, sentinel 架构的主要作用是解决主从模式下主节点的故障转移工作的。这里如果主节点因为故障下线,那么某个 sentinel 节点发送检测消息给主节点时,如果在指定时间内收不到回复,那么该 sentinel 就会主观的判断该主节点已经下线,那么其会发送消息给其余的 sentinel 节点,询问其是否“认为”该主节点已下线,其余的 sentinel 收到消息后也会发送检测消息给主节点。

如果其认为该主节点已经下线,那么其会回复向其询问的 sentinel 节点,告知其也认为主节点已经下线,当该 sentinel 节点最先收到超过指定数目(配置文件中配置的数目和当前 sentinel 节点集合数的一半,这里两个数目的较大值)的 sentinel 节点回复说当前主节点已下线,那么其就会对主节点进行故障转移工作,故障转移的基本思路是在从节点中选取某个从节点向其发送 slaveof no one (假设选取的从节点为127.0.0.1:6380),使其称为独立的节点(也就是新的主节点),然后 sentinel 向其余的从节点发送 slaveof 127.0.0.1 6380 命令使它们重新成为新的主节点的从节点。

重新分配之后 sentinel 节点集合还会继续监控已经下线的主节点(假设为 127.0.0.1:6379 ),如果其重新上线,那么 sentinel 会向其发送 slaveof 命令,使其成为新的主机点的从节点,如此故障转移工作完成。

上面我们讲到了,每个 sentinel 节点在本质上还是一个redis实例,只不过和redis数据节点不同的是,其主要作用是监控redis数据节点。在redis安装目录下有个默认的 sentinel 配置文件 sentinel.conf ,和配置主从节点类似,这里复制三个配置文件: sentinel-26379.conf sentinel-26380.conf sentinel-26381.conf 。分别按照如下示例编辑这三个配置文件:


port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel myid mm55d2d712b1f3f312b637f9b546f00cdcedc787


对于端口为26380和26381的 sentinel ,其配置和上述类似,只需要把相应的端口号修改为对应的端口号即可。这里注意两点:

  • 每个 sentinel 的myid参数也要进行修改,因为 sentinel 之间是通过该属性来唯一区分其他 sentinel 节点的;

  • 参数中 sentinel monitor mymaster 127.0.0.1 6379 2 这里的端口号6379是不用更改的,因为 sentinel 是通过检测主节点的状态来得知当前主节点的从节点有哪些的,因而设置为主节点的端口号即可。

配置完成后我们首先启动三个主从节点,然后分别使用三个配置文件使用如下命令启用 sentinel







请到「今天看啥」查看全文