Redis主从复制的配置并进行场景测试

本文深入探讨Redis主从复制的配置方法及其实现原理,通过实际场景测试验证其在数据冗余、崩溃恢复和负载均衡方面的应用效果。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis主从复制的配置并进行场景测试

为什么要使用主从复制?

Redis虽然读写的速度相对于传统的关系型数据库较快,但是也会出现读取压力比较大的情况,为了避免出现这种情况的发生,以免给用户造成不好的体验,这时候就要考虑Redis的主从复制了。所谓主从复制,就是一个master下有多个slave节点。用户对于数据的操作,都是读远远大于写的,所以我们只在master节点下进行写的操作,而读就交给slave节点,这样就很好的分摊压力,保证Redis的读写性能。
在Redis中,数据的复制都是单向的,只能从Master节点复制到Salve节点。而一个Salve节点只能有一个Master节点。

主从复制的作用:

  • 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
  • 崩溃恢复:当Master节点出现错误时,从节点会担当重任,来保证数据的读写操作可正常进行,快速的实现故障修复。
  • 负载均衡:在主从复制的基础上,配合使用读写分离,可以由主节点实现写操作,从节点提供读操作,分担服务器的压力。尤其是读多写少的情况下,通过多个Salve节点分担读操作,可以极大的提高Redis的并发量。

在这里插入图片描述
我们可以在Master节点写配置多个Salve节点,而Salve节点下依然可以配置多个Salve节点。

手动配置实现一主多从:

虽然通过命令行我们也可以对从节点进行配置,但是一旦宕机配置就会失效,所以我这里采用的是配置文件进行配置。

配置文件进行配置(以一台服务器配置多个redis.conf文件达到一主多从的目标为例):
打开redis.conf配置文件我们可以找到REPLICATION节点。只需配置从节点的配置文件即可,Master节点不需要操作。

slaveof <masterip> <masterport>    #salveof master节点IP master节点端口
masterauth <master-password>       #如果master节点有密码,需要在此配上密码
slave-serve-stale-data yes         #主从复制中,从服务器可以响应客户端请求
slave-read-only yes                #从节点只读,不可写
repl-diskless-sync no              #默认不使用diskless同步方式 
repl-diskless-sync-delay 5         #无磁盘diskless方式在进行数据传递之前会有
一个时间的延迟,以便slave端能够进行到待传送的目标队列中,这个时间默认是5秒
repl-timeout 60                    #设置超时时间 

在配置之前我们先通过命令查看一下6379Master节点是否存在Salve节点:

127.0.0.1:6379> info replication
# Replication
role:master               #该节点为Master节点
connected_slaves:0        #没有从节点
master_replid:26dda30d25e234451caf414978532d5a1a55b257
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379> 

如果我们想把该Redis6380变成某一个Redis6379的Salve节点,那么需要修改slaveof Redis6379的IP Redis6379的端口号,除此之外还有port、pidfile、logfile、dbfilename这四个地方需要更改以免和Master节点冲突(针对在一台服务器配置多个redis.conf文件来实现一主多从的方式需要修改port、pidfile、logfile、dbfilename)如果有Master节点有密码那么还需要修改masterauth Redis6379的密码
完成以上两个配置,Redis6380就变成了Redis6379的从节点。
配置文件修改完毕之后我们查看一下进程是否都正常启动:

在这里插入图片描述
我们可以看到6379和6380以及6381端口都正常启动了。
那我们再来看下此时6380节点的信息:

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:9
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:8aba049a5b9bcec45ad5afa87fa5c7f682189d40
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42
127.0.0.1:6380> 

我们可以看到,6380的role是Slave,他的Master节点的IP为127.0.0.1 端口号为6379等一些Master的信息。同样的在6381节点看到的也和6380看到的一样。那此时Master节点的信息会变成什么样呢?我们来看一下。

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=364,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=364,lag=1
master_replid:8aba049a5b9bcec45ad5afa87fa5c7f682189d40
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:364
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:364
127.0.0.1:6379> 

在Master节点中我们可以看到他下面的两个Salve节点的信息。

场景测试

既然主从复制已经配置好了,那我们不妨测试几个场景:

  • 场景一:在Master节点插入数据,看在两个Salve节点是否能查询的到
  • 场景二:6380节点突然宕掉,这时Master节点还在插入数据,重新启动6380,看能否查到宕机期间Master插入的数据。
  • 场景三:Master突然宕机,两个Salve节点是否能正常查询。

场景一测试结果:

#在Master6379节点插入一条数据
127.0.0.1:6379> set name Silence
OK
127.0.0.1:6379> get name
"Silence"
127.0.0.1:6379> 
#6380Salve节点可以获取到Master节点插入的数据
127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380>
#6381Salve节点可以获取到Master节点插入的数据
127.0.0.1:6381> get name
"Silence"
127.0.0.1:6381> 

由此可以看出,我们在Master节点插入的数据在两个Salve节点是可以查询到的。

场景二测试结果:
我们把6380Salve节点的进程kill掉,然后在Master节点插入数据。

[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:02 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6307     1  0 16:37 ?        00:00:01 redis-server 127.0.0.1:6380
root      6315  6283  0 16:37 pts/1    00:00:00 redis-cli -p 6380
root      6343     1  0 16:41 ?        00:00:01 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6403  6382  0 17:00 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# kill 6307
[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:02 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6315  6283  0 16:37 pts/1    00:00:00 redis-cli -p 6380
root      6343     1  0 16:41 ?        00:00:01 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6405  6382  0 17:00 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# 

6380Salve节点的服务已经被kill掉。
在Master节点插入数据:
这是Master和两个Salve节点查询数据的状态是这样的:

127.0.0.1:6379> set name Silence
OK
127.0.0.1:6379> get name
"Silence"
127.0.0.1:6379> set name wen
OK
127.0.0.1:6379> get name
"wen"
127.0.0.1:6379> 

#6380Salve节点
127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380> get name
Could not connect to Redis at 127.0.0.1:6380: Connection refused
not connected> 

#6381Salve节点
127.0.0.1:6381> get name
"Silence"
127.0.0.1:6381> get name
"wen"
127.0.0.1:6381> 

分析执行结果可以看到,Master和6381Salve节点都是可以正常获取到插入的数据,而6380是获取不到的。那么现在我们重新启动一下6380节点,并获取数据看能否获取到宕机期间Master插入的数据。

127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380> get name
Could not connect to Redis at 127.0.0.1:6380: Connection refused
not connected> exit
[root@Silence bin]# redis-server redis6380.conf 
[root@Silence bin]# redis-cli -p 6380
127.0.0.1:6380> get name
"wen"
127.0.0.1:6380>

咦?在6380宕机期间Master插入的数据在6380恢复服务之后竟然还可以查到,由此可见主从复制是多么的牛X!

场景三测试结果:
我们把Master节点给kill掉。

[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:03 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:02 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:00 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6431  6382  0 17:08 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# kill 6254
[root@Silence /]# ps -ef|grep redis
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:02 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:00 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6433  6382  0 17:08 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# 

这时候再去两个Salve节点查询数据。

#6380Salve节点依然可以查询的到之前Master节点插入的数据
127.0.0.1:6380> get name
"wen"

#6381Salve节点也依然可以查询的到之前Master节点插入的数据
127.0.0.1:6381> get name
"wen"

虽然两个Salve节点仍然可以查到Master节点之前插入的数据,但是用户有新数据插入的话两个Salve节点可以插入数据吗?
答案是不可以,不信的话我们可以来试试

127.0.0.1:6380> set age 23
(error) READONLY You can't write against a read only replica.  
127.0.0.1:6380> 

127.0.0.1:6381> set age 25
(error) READONLY You can't write against a read only replica.  
127.0.0.1:6381> 

根据结果可以看出,两个Salve节点是无法插入数据的。

那么问题就来了,当Master突然宕机了,写入操作该怎么办?请看下篇文章。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Silence-wen

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值