本文主要是介绍Redis 15 主从复制，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

参考源

https://www.bilibili.com/video/BV1S54y1R7SB?spm_id_from=333.999.0.0

版本

本文章基于 Redis 6.2.6

概述

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器

前者称为主节点（master / leader），后者称为从节点（slave / follower）。

数据的复制是单向的，只能由主节点到从节点。

Master 以写为主，Slave 以读为主。

一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

默认情况下，每台 Redis 服务器都是主节点。

作用

数据冗余

主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

故障恢复

当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。这也是一种服务的冗余。

负载均衡

在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载。

尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。

高可用

主从复制是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

一般来说，要将 Redis 运用于工程项目中，只使用一台 Redis 是万万不能的，原因如下：

• 结构上：单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。

• 容量上：单个 Redis 服务器内存容量有限，一般来说，单台 Redis 最大使用内存不应该超过 20G。

应用

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是多读少写。

对于这种场景，我们可以使用如下这种架构：

环境配置

命令方式

指定主库（配从库不配主库）

slaveof 主库IP 主库端口

这种方式每次与主库断开后，都需要重新连接，非常不方便，不推荐。

配置文件方式

拷贝多个 redis.conf 文件

标准的配置是一主三从，受限于内存大小，这里演示一主二从，所以拷贝 3 份配置文件演示。

[root@sail redis]# cp redis.conf redis6379.conf
[root@sail redis]# cp redis.conf redis6380.conf
[root@sail redis]# cp redis.conf redis6381.conf

修改配置文件

修改 redis6379.conf

daemonize yes
pidfile /var/run/redis_6379.pid
logfile "6379.log"
dbfilename dump6379.rdb

修改 redis6380.conf

daemonize yes
pidfile /var/run/redis_6380.pid
logfile "6380.log"
dbfilename dump6380.rdb

修改 redis6381.conf

daemonize yes
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump6381.rdb

一主二从

启动服务

[root@sail redis]# redis-server redis6379.conf
[root@sail redis]# redis-server redis6380.conf
[root@sail redis]# redis-server redis6381.conf

查看启动的服务

[root@sail redis]# ps -ef|grep redis
root      8066  6267  0 21:40 pts/3    00:00:00 redis-cli -p 6380
root      8388     1  0 21:46 ?        00:00:00 redis-server 127.0.0.1:6380
root      8397     1  0 21:46 ?        00:00:00 redis-server 127.0.0.1:6381
root      8417  6213  0 21:47 pts/0    00:00:00 grep --color=auto redis
root     11953     1  0 Mar15 ?        02:02:44 ./bin/redis-server *:6379

查看主从复制信息

info replication

默认三个都是 master，都是主机。

配置为一个 master 两个 slave

slaveof 地址 端口号

也可以通过配置文件直接指定主机，这样比较方便，也便于维护。

主机赋值，从机取值

从机是不能赋值的，这样就实现了读写分离。

主机断开

主机断开以后从机依然是从机，且正常工作。

主机恢复

主机恢复以后赋的值从机依然能够读取到，这样可以保证高可用。

从机断开

从机断开后，主机赋了新值，从机启动后无法获取到新值，原因是从机启动后又默认为主机了。

如果想启动即为从机，可以按照前面说的配置 replicaof 进行设置。

层层链路

从机也可以被其他从机当作主机，可以有效减轻主机的写压力。

6381 指定 6380 作为主机，6380 依然是从机，只是有了从机节点。

这样 6379 赋的值只需要复制到 6380，6380 再复制到 6381，这样就有效的减轻主机的写压力。

谋朝篡位

slaveof no one

主机断开后，从机如果想要当主机，可以使用 slaveof no one 进行“谋朝篡位”，从而变成主机。

但此时其他节点还是很“忠心”，依然认定之前的主机为主机，这样变成的主机是没有从机的，是个“孤家寡人”。

主机如果恢复，可以“平息叛乱”，之前的从机依旧认定它为主机。

改朝换代

前面的操作在实际场景中并不适用，因为我们希望的是主机断开后有从机作为主机，依旧实现主从复制。

所以在从机“谋朝篡位”后，还需要让剩余的从机“认主”，让他们都“归顺”于新的主机。

这样原来的主机恢复后就变成了“孤家寡人”。

以上的配置十分繁琐，任何一个环节出错都可能导致失败。

下一章节将介绍更加智能也是工作中常用的哨兵模式。

这篇关于Redis 15 主从复制的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！