Redis主从复制

最新推荐文章于 2025-10-11 17:10:57 发布

原创最新推荐文章于 2025-10-11 17:10:57 发布 · 352 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #linux #分布式 #数据库 #java

NoSQL 专栏收录该内容

4 篇文章

订阅专栏

一、redis的主从复制

redis是高性能的内存数据库，一旦断电就会丢失数据，因此，它具备了持久化，可以将内存中的数据保存在磁盘中。但是，当有大量的并发时，redis的压力也会增大，我们就使用了读写分离的方式，将读和写进行分离，要实现读写分离，必须保证数据的一致性。因此，我们可以使用主从复制的方式。

1.1 redis主从复制的机构分类

redis的主从复制的结构分为两种，一主多从和级联方式。

一主三从在这里插入图片描述
级联

1.2 什么是redis的主从复制

前面说了redis的为什么会使用主从复制和它的分类，那到底什么是主从复制呢？
主从复制就是指将主数据库的内容复制给从数据库，达到主从数据库数据的一致性。redis的主从复制是同理的，在这样的情况下，就可以实现读写分离，不会产生读到的数据不是最新数据的情况。

二、redis主从复制的环境搭建

理论终究是理论，我们应该将理论转化为实际的代码进行验证。这里我们搭建一个简单的主从复制的环境。

2.1 准备

最简单的主从复制就应该是一主二从，至少三台服务器。因为，我们要考虑到实际开发的意外，当一个从数据库宕机了，我们还能保证系统的正常。
博主条件有限，这里就在一台服务器上打开三个redis服务。

2.2 步骤

1.在服务器上准备三个redis服务
因为redis启动时，会加载它的redis.conf配置。我们准备三个redis.conf配置文件。（博主将redis.conf文件放在了bin目录下的softconf文件夹下。）分别以端口号进行命名。
在这里插入图片描述
2.修改配置文件
我们需要将redis配置文件里的一些配置项进行修改，如下。
此处以6380为例。

# 三个redis的端口分别为6379、6380、6381
port 6380
daemonize yes # 守护线程 后台启动
pidfile /var/run/redis_6380.pid # pid
logfile "6380.log" # 日志文件
dbfilename dump6380.rdb # 持久化文件
replicaof 127.0.0.1 6379 # 主ip 主端口   老版本是slaveof   从服务才修改此处，6379不要这一个配置

3.开启端口
这里有三个redis的实例，我们需要将这三个实例的端口在防火墙和腾讯云（其他一样）的安全组中开放。

# 查看防火墙开放的端口
[root@VM-0-15-centos softconf]# firewall-cmd --list-ports 
8080/tcp 80/tcp 9000/tcp 20/tcp 21/tcp 22/tcp 8888/tcp 39000-40000/tcp 888/tcp 6379/tcp
#开放6380端口
[root@VM-0-15-centos softconf]# firewall-cmd --zone=public --add-port=6380/tcp --permanent
success
# 开放6381端口
[root@VM-0-15-centos softconf]# firewall-cmd --zone=public --add-port=6381/tcp --permanent
success
# 重新加载防火墙配置，不然没用
[root@VM-0-15-centos softconf]# firewall-cmd --reload # 配置立即生效

4.启动redis

通过配置文件启动redis，并用指定端口打开redis客户端。此处以6379为例。

[root@VM-0-15-centos bin]# redis-server softconf/redis6379.conf 
[root@VM-0-15-centos bin]# redis-cli -p 6379

如果不配置replicaof,redis默认都是主服务。但是加上了，可以看到6379是主服务，它下面有两个从服务。
在这里插入图片描述
这里以6380为例，可见它是从服务。

5.测试

场景：我们在主服务上进行数据写入。在从服务上进行数据读取。

# 主服务 6379
127.0.0.1:6379> set k1 v1
OK


# 从服务 6380
127.0.0.1:6380> keys *
1) "k1"
127.0.0.1:6380> get k1
"v1"


# 从服务 6381
127.0.0.1:6381> keys *
1) "k1"
127.0.0.1:6381> get k1
"v1"

结果：主服务可以写入数据，从服务可以读取数据！！！

场景：测试主服务是否可以读取数据，从服务是否可以写入数据
在上一个场景数据不变的情况下进行如下测试。

127.0.0.1:6379> get k1
(nil)

127.0.0.1:6380> set k2 v2
(error) READONLY You can not write against a read only replica.

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

结果：主服务无法读取数据，从服务写入数据！！！

场景：关闭主服务，从服务是否可以写入数据？是否可以读取数据？是否会成为主服务？
结果：从服务无法写入，可以读取，没用成为主服务。

4.场景：重启主服务，主服务能否写入/读取数据? 从服务能够读取/写入数据？
结果：主服务能够读取/写入数据，从服务只能读取数据
此处的结果，似乎有点文件…应该不能读取才对

哨兵模式

1. 应用场景

常规的主从复制，可以发现当服务器正常运行时，是没有问题的，但是，当某一个服务器宕机后，就会出现问题，如果，主服务宕机，就没有了写入功能，如果从服务宕机，就没有了读取功能。这时候就需要人去手动启动并设置。
哨兵模式就可以完美的解决这个问题，当某一台服务发生了问题，它会去判断该服务是否已经死掉，如果确定死掉，就会自动的去设置其他的服务替代死掉的服务。
一般来说，哨兵模式也会怕哨兵线程死掉，因此也会用集群的思想，去布置多个哨兵共同监视，并相互监听。
在这里插入图片描述

2. 哨兵模式搭建

此处搭建最简单的一种，一个哨兵监控master

sentinel.conf
哨兵的配置文件

#配置端口
port 26379
#以守护进程模式启动
#daemonize yes
#日志文件名
#logfile "sentinel_26379.log"
#存放备份文件以及日志等文件的目录
#dir "/opt/redis/data"
#监控的IP 端口号 名称 sentinel通过投票后认为mater宕机的数量，此处为至少1个
sentinel monitor mymaster 127.0.0.1 6379 1
#30秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，三分钟内没有完成，则认为转移失败
sentinel failover-timeout mymaster 180000

如果redis服务器配置了密码连接,则要增加如下配置:
这行配置要配置到 sentinel monitor mymaster ip port 后面,因为名称 mymaster要先定义.

sentinel auth-pass mymaster 123456

启动哨兵

redis-sentinel softconf/sentinel.conf

在这里插入图片描述

验证主从切换
杀掉主服务的进程

可以看到主程序的界面如下

此时观察哨兵的日志信息。重点观察圈中的部分。

switch-master表示切换主服务。将主服务6379切换到6381上。
此时查看6381的复制信息。可以看到6381已经是主服务了。它下面有一个从服务，是6380.

我们可以在6380查看

3. 哨兵模式原理

此处，我只搭建了一个哨兵，实际开发中，都是会搭建一个哨兵集群。
简单说一下原理。
①、三个定时任务
　　一.每10秒每个 sentinel 对master 和 slave 执行info 命令:该命令第一个是用来发现slave节点,第二个是确定主从关系.
　　二.每2秒每个 sentinel 通过 master 节点的 channel(名称为_sentinel_:hello) 交换信息(pub/sub):用来交互对节点的看法(后面会介绍的节点主观下线和客观下线)以及自身信息.
　　三.每1秒每个 sentinel 对其他 sentinel 和 redis 执行 ping 命令,用于心跳检测,作为节点存活的判断依据.
②、主观下线和客观下线
　　一.主观下线
　　SDOWN:subjectively down,直接翻译的为”主观”失效,即当前sentinel实例认为某个redis服务为”不可用”状态.
　　二.客观下线
　　ODOWN:objectively down,直接翻译为”客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制.
③、故障转移
　　故障转移是由 sentinel 领导者节点来完成的(只需要一个sentinel节点),关于 sentinel 领导者节点的选取也是每个 sentinel 向其他 sentinel 节点发送我要成为领导者的命令,超过半数sentinel 节点同意,并且也大于quorum ,那么他将成为领导者,如果有多个sentinel都成为了领导者,则会过段时间在进行选举.

原理部分可以参考这一个博主的文章https://www.cnblogs.com/ysocean/p/12290364.html