前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Redis主从复制(二)

Redis主从复制(二)

作者头像
江南一点雨
发布2018-07-31 16:36:41
3810
发布2018-07-31 16:36:41
举报
文章被收录于专栏:玩转JavaEE玩转JavaEE

上篇文章和小伙伴们一起搭建了redis主从复制环境,但是还不完善,本文我想再和小伙伴们聊聊主从复制环境搭建的一些细节。

一场接力赛

在上篇文章中,我们搭建的主从复制模式是下面这样的:

实际上,一主二仆的主从复制,我们可以搭建成下面这种结构:

搭建方式很简单,在前文基础上,我们只需要修改6381的master即可,在6381实例上执行如下命令,让6381从6380实例上复制数据,如下:

代码语言:javascript
复制
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK

此时,我们再看6379的slave,如下:

代码语言:javascript
复制
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=1
master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0

只有一个slave,就是6380,我们再看6380的信息,如下:

代码语言:javascript
复制
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:70
slave_priority:100
slave_read_only:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=70,lag=0
master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70

6380此时的角色是一个从机,它的主机是6379,但是6380自己也有一个从机,那就是6381.此时我们的主从结构如下图:

哨兵模式

结合上篇文章,我们一共介绍了两种主从模式了,但是这两种,不管是哪一种,都会存在这样一个问题,那就是当主机宕机时,就会发生群龙无首的情况,如果在主机宕机时,能够从从机中选出一个来充当主机,那么就不用我们每次去手动重启主机了,这就涉及到一个新的话题,那就是哨兵模式。

所谓的哨兵模式,其实并不复杂,我们还是在我们前面的基础上来搭建哨兵模式。假设现在我的master是6379,两个从机分别是6380和6381,两个从机都是从6379上复制数据。先按照上文的步骤,我们配置好一主二仆,然后在redis目录下打开sentinel.conf文件,做如下配置:

代码语言:javascript
复制
sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster是给要监控的主机取的名字,随意取,后面是主机地址,最后面的2表示有多少个sentinel认为主机挂掉了,就进行切换(我这里只有一个,因此设置为1)。好了,配置完成后,输入如下命令启动哨兵:

代码语言:javascript
复制
redis-sentinel sentinel.conf

然后启动我们的一主二仆架构,启动成功后,关闭master,观察哨兵窗口输出的日志,如下:

小伙伴们可以看到,6379挂掉之后,redis内部重新举行了选举,6380重新上位。此时,如果6379重启,也不再是扛把子了,只能屈身做一个slave了。

注意问题

由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。因此我们还需要集群来进一步提升redis性能,这个问题我们将在后面说到。

OK,redis主从复制问题我们就介绍这么多,更多资料小伙伴们可以参考官方文档http://www.redis.net.cn/tutorial/3501.html。小伙伴在看官方文档时,有什么问题欢迎留言讨论。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-06-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 江南一点雨 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一场接力赛
  • 哨兵模式
  • 注意问题
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档