目录
- 一、主从复制概念
- 二、单机安装Redis
- 2.1、安装 Redis 需要的软件 gcc 和 tcl
- 2.2、上传Redis压缩包
- 2.3、编辑 redis.conf 文件
- 2.4、执行安装 Redis 命令
- 2.5、注意防火墙配置
- 三、主从复制 - 环境搭建
- 3.1、配置一个 master 节点，两个 slave 节点
- 3.2、配置 redis6379.conf (master)
- 3.3、配置 redis6380.conf（slave）、redis6381.conf（slave）
- 3.4、基本操作命令
- 3.4.1、info replication
- 3.4.2、slaveof 192.168.56.105 6380
- 四、常用三招
- 4.1、一主二仆
- 4.1.1、方案1 配置文件指定主机从机
- 4.1.1.1、配置两个从机 redis6380.conf 和 redis6381.conf
- 4.1.1.2、依次启动
- 4.1.1.3、主从关系查看
- 4.1.2、方案2 命令操作手动指定（这种方式重启之后就无效了）
- 4.2、薪火相传
- 4.3、反客为主
- 五、复制原理
- 5.1、全量同步（第一次连接或偏移量超出back_log缓冲区）
- 5.2、增量同步（非第一次）
- 5.3、复制原理整体概述
- 5.4、主从复制的缺点
一、主从复制概念
- 概念：主从复制，是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master/Leader),后者称为从节点(Slave/Follower)数据的复制是单向的!只能由主节点复制到从节点(主节点以写为主、从节点以读为主)
- 默认情况下,每台Redis服务器都是主节点,一个主节点可以有0个或者多个从节点,但每个从节点只能有一个主节点
- 主从复制作用
- 读写分离,性能扩展(主节点负责写入、从节点负责读取)
- 容灾快速恢复(一般建议配置一主多从的方式、当从服务器A出现问题,可以快速切换到从服务器B)
- 如果当主服务器出现问题呢？这个时候可以配置一主多从集群模式A、B,A、B之间建立某种联系,当主A出现问题,马上可以切换到主B
二、单机安装Redis
2.1、安装 Redis 需要的软件 gcc 和 tcl
安装 gcc ：
yum install gcc
安装 tcl :
yun install tcl
2.2、上传Redis压缩包
解压缩文件：
tar -zxvf redis-6.2.4.tar.gz
2.3、编辑 redis.conf 文件
- 修改端口号，设置任意 IP 都可以访问
- 给 Redis 设置密码（在后续有配置）
2.4、执行安装 Redis 命令
进入到 redis 解压目录 ，执行命令
make && make install
# 启动命令
redis-server redis.conf
# 使用redis-cli连接redis
# -p 指定连接的端口号
redis-cli -p 6379
# 指定 redis
redis-cli shutdown
# 需要密码认证 redis 是密码
redis-cli -a redis shutdown
# 在 redis-cli 中 输入 也可以关闭 Redis
shutdown
Ctril + c
关闭命令：
安装成功的结果：
2.5、注意防火墙配置
启动： systemctl start firewalld
关闭： systemctl stop firewalld
查看状态： systemctl status firewalld
开机禁用 ： systemctl disable firewalld
开机启用 ： systemctl enable firewalld
添加 ：firewall-cmd --zone=public --add-port=80/tcp --permanent （--permanent永久生效，没有此参数重启后失效）
重新载入： firewall-cmd --reload
查看： firewall-cmd --zone= public --query-port=80/tcp
删除： firewall-cmd --zone= public --remove-port=80/tcp --permanent
三、主从复制 - 环境搭建
**注意：**第 11 步，是从机需要配的，主机不需要配置；（前10步是主从都需要配置的；）
3.1、配置一个 master 节点，两个 slave 节点
备份好redis.conf文件;
复制文件的命令：
# 拷贝命令
cp redis-6.2.4/redis.conf redis.conf
# 重命名文件名
mv redis.conf redis6379.conf
# 查看关于redis正在运行的进程
ps -ef | grep redis
操作中包括这三个配置文件：redis6379.conf（master）、redis6380.conf （slave）、redis6381.conf （slave）
3.2、配置 redis6379.conf (master)
- 开启 daemonize yes
daemonize yes:以守护进程的方式运行,默认是 no,我们需要自己开启为yes,如果以后台的方式运行,我们就需要指定一个 pid 文件! pidfile /var/run/redis_6379.pid
**注意：**如果以后台的方式运行,我们就需要指定一个 pid 文件!
- 注释点 bind 127.0.0.1 或者 改为 bind 0.0.0.0
#bind 127.0.0.1 //不绑定任何网络接口，只连接本地
- 关闭 Redis 保护 protected-mode no
protected-mode:yes 是否开启保护模式,Redis默认开启,如果没有设置bind的IP地址和Redis密码,那么服务就会默认只能在本机运行
1.保护你的redis实例，防止被访问和利用
2.大白话：只有本地才能操作这个实例，外网不行
- 指定端口号 port 6379
- 指定当前工作目录 dir
持久化文件保存的目录,默认保存在当前目录下
dir /root/redis/work # 这个配置会将该appendfilename "appendonly.aof"这种配置的文件名写到/root/redis/work这个目录下
- pid 文件名字 pidfile
- log 文件名字 logfile
- 设置redis 密码
- 指定 rdb 持久化的文件名
- 开启 AOF 持久化
1.appendonly是一个用于配置是否开启AOF（Append Only File）持久化方式的参数。
2.默认情况下，appendonly的值为no，表示未启用AOF。
3.AOF持久化是一种将写操作追加到文件末尾的方式，它记录了所有对Redis数据集的写操作命令。通过启用AOF，Redis可以在重新启动时根据AOF文件的内容来恢复数据集。如果您希望启用AOF持久化方式，可以通过编辑redis.conf文件来完成。找到名为appendonly的行，并将其值修改为yes
- 开启 logo （非必须）
开启这个配置，在日志文件中会打印 Redis 图像
展示：
3.3、配置 redis6380.conf（slave）、redis6381.conf（slave）
配置完 3.2 十个步骤之后，这两个文件需要另外配置 要连接的主节点的 ip ，端口 ,密码；
- 从机配置上主机的ip、端口
- 配置主节点的redis密码
3.4、基本操作命令
# 查看复制节点的主从关系和配置信息
info replication
# replicaof/slaveof 这两个一样，一般写入进 redis.conf 配置文件内，
# 在运行期间修改slave节点的信息，如果该数据库已经某个数据库的从数据库，
# 那么会停止和原主数据库的同步关系转而和新的主数据库同步
replicaof/slaveof 主库IP 主库端口
# 使当前数据库停止与其他数据库的同步，升级为主数据库
replicaof/slaveof no one
3.4.1、info replication
主节点：
从节点：
3.4.2、slaveof 192.168.56.105 6380
6381 这个执行 slaveof 语句
切换主节点 到 6380 的情况
执行命令之后 6381的状态：
执行命令之后 6380的状态：
四、常用三招
4.1、一主二仆
4.1.1、方案1 配置文件指定主机从机
4.1.1.1、配置两个从机 redis6380.conf 和 redis6381.conf
设置主机IP、端口、和redis密码；
4.1.1.2、依次启动
redis6379.conf
redis-server /root/redis/redis6379.conf
redis-cli -a redis -p 6379
redis6380.conf
redis-server /root/redis/redis6380.conf
redis-cli -a redis -p 6380
redis6381.conf
redis-server /root/redis/redis6381.conf
redis-cli -a redis -p 6380
4.1.1.3、主从关系查看
- 日志查看
- 主机
b. 从机（以一台为例）
- 命令查看
info replication
1. 主机
1. 
2. 从机
1. 
4.1.2、方案2 命令操作手动指定（这种方式重启之后就无效了）
手动指定的配置：
https://tangzhi.blog.csdn.net/article/details/126686223
4.2、薪火相传
- 上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻主master的写压力
- 中途变更转向：会清除之前的数据，重新建立拷贝最新的
- slaveof/replicaof 新主库IP 新主库端口
4.3、反客为主
- slaveof/replicaof no one 使当前数据库停止与其他数据库的同步，转成主数据库
五、复制原理
5.1、全量同步（第一次连接或偏移量超出back_log缓冲区）
第一次连接全量同步的情况：
复制偏移量超出 back_log 缓冲区，进行全量同步的情况：
- rpid : 数据集 id
- offset : 复制偏移量（replication offset）
- 与第一次连接全量同步的差别为，slave 节点在第一次发送请求时，发送的是 数据集id (rpid) 和 offset (复制偏移量)；
- Redis 通过同步（sync）和指令传播（command propagate）两个操作完成同步；
- 同步（sync）：将从节点的数据库状态更新至与主节点的数据库状态一直的操作；
而全量同步，是发生在下面这两个时间节点的：
- 当 slave 节点第一次连接 master 节点时，会进行全量同步；
- 当 slave 节点断开时间过长，back_log 中的 offset 已经被覆盖了，会进行全量同步；
- back_log 的结构是一个环形缓冲区，用来存储主节点向从节点传递的命令，它的大小是固定的，可存储的命令有限，超出的部分将会被删除；从而导致上边的第二点；
- back_log 的结构是一个环形缓冲区，用来存储主节点向从节点传递的命令，它的大小是固定的，可存储的命令有限，超出的部分将会被删除；从而导致上边的第二点；
全量同步大概有以下三个阶段：
- 阶段一：slave 从节点 通过 replicaof/slaveof 命令与master节点建立连接
- slave 节点发送同步请求（SYNC指令）；
- master 节点收到同步请求（SYNC指令），判断 slave 节点是不是第一次同步；
- 如果是第一次同步，则返回master节点的版本信息；进行slave节点的初始化；
- 阶段二：master节点进行数据持久化，并发送给slave节点
- master 节点执行 bgsave ,生成 RDB 文件；
- 在生成 RDB 文件期间，还会记录下该期间执行的所有命令，记录在back_log里面；
- master 节点把生成的 RDB 文件，发送给 slave 节点；
- slave 节点会先清空本地的数据，然后根据 RDB 文件加载数据；
- master 节点执行 bgsave ,生成 RDB 文件；
- 阶段三：把在生成 RDB 文件期间执行的命令(back_log) 发送给 slave 节点；
- master 节点 将 生成RDB文件期间执行的命令 (存储在 back_log文件中)，发送给 slave节点；
- slave 节点执行 back_log 中的命令，同时修改偏移量 (replication offset);
注意：
在Redis的主从复制中，当从节点连接到主节点并请求进行复制时，主节点会返回给从节点版本信息，其中包括以下内容：
- Redis 服务器的版本信息：主节点会向从节点发送自己的Redis服务器版本信息，包括主节点正在运行的Redis版本号。
- 主节点的复制偏移量（replication offset）：这是指主节点当前数据库中最后一次执行的命令的复制偏移量，从节点将会使用这个偏移量来进行部分同步（PSYNC）操作，以便快速地获取到主节点数据的副本。
从节点在接收到主节点的版本信息之后，将会使用这些信息来进行初始化同步或部分重同步，以确保从节点与主节点的数据一致性。
5.2、增量同步（非第一次）
发生增量同步的时间节点：
- slave 节点断开又恢复了，且断开的时间短（在master节点的 back_log 文件中能够找到 复制偏移量（replication offset）的时候）【如果在找不到复制偏移量的话则会执行全量复制】；
增量同步有两个阶段：
- 第一阶段：slave 阶段重启，重新连接master节点
- slave 节点重新连接 master 节点后，会向master 节点发送 数据集id(rpid), 偏移量(offset)
- master 节点判断 数据集id(rpid) 是否相同；
- 如果数据集相同，则说明不是第一访问，恢复给 slave 节点 continue ；
- 第二阶段：同步数据 （对比 back_log 抽象图）
- master 节点去back_log中获取slave节点宕机后执行的命令（通过比对 slave节点传过来的 offset ）
- master 节点向 slave 节点发送，offset 之后的命令；
- slave 节点执行命令，保证数据一致性；
5.3、复制原理整体概述
- slave 启动，同步初请
- slave 启动成功连接到 master 后会发送一个 sync 命令
- slave 首次全新连接 master ，一次完全同步（全量复制）将被自动执行，slave 自身原有数据会被master 数据覆盖清除；
- 首次连接，全量复制
- master节点收到sync命令后会在后台开始保存快照（即RDB持久化，主从复制会触发RDB），同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化后，master将rdb快照文件和缓存的命令发送到所有slave，已完成一次完全同步
- 而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化
- 心跳持续，保持通信
- repl-ping-replica-period 10
- master发出PING包的周期，默认是10秒
- 进入平稳，增量复制
- master 继续将新的所有收集到的修改命令自动一次传给slave，完成同步
- 从机下线，重连续传
- master 会检查backlog里面的offset，master和slave都会保存一个复制的offset 还有一个masterId
- offset 是保存在backlog 中的。master只会把已经复制的offset后面的数据赋值给slave，类似断电续传
5.4、主从复制的缺点
- 复制延时，信号衰减
- 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
- master挂了
- 默认情况下不会在slave节点自动重选一个master
- 需要人工干预
