Redis从入门到精通(十三)Redis分布式缓存(一)RDB和AOF持久化、Redis主从集群的搭建与原理分析

文章目录

第5章 Redis分布式缓存
- 5.1 Redis持久化
- - 5.1.1 RDB持久化
  - - 5.1.1.1 执行时机
    - 5.1.1.2 bgsave原理
  - 5.1.2 AOF持久化
  - - 5.1.2.1 AOF原理
    - 5.1.2.2 AOF配置
    - 5.1.2.3 AOF文件重写
  - 5.1.3 RDB和AOF的对比
- 5.2 Redis主从
- - 5.2.1 搭建主从结构
  - 5.2.2 主从数据同步原理
  - - 5.2.2.1 全量同步
    - 5.2.2.2 增量同步
  - 5.2.3 小结

第5章 Redis分布式缓存

单机Redis存在四大问题：

1）数据丢失问题；
2）并发能力问题；
3）故障恢复问题；
4）存储能力问题。

而Redis分布式缓存，即基于Redis集群来解决单机Redis存在的问题：

1）数据丢失问题：实现Redis数据持久化；
2）并发能力问题：搭建主从集群，实现读写分离；
3）故障恢复问题；利用Redis哨兵，实现健康监测和自动恢复；
4）存储能力问题：搭建分片集群，利用插槽机制实现动态扩容。

5.1 Redis持久化

Redis有两种持久化方案：

RDB持久化
AOF持久化

5.1.1 RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说，就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

5.1.1.1 执行时机

RDB持久化在四种情况下会执行：执行save命令、执行bgsave命令、Redis停机时、触发RDB条件时。

1）执行save命令

127.0.0.1:6379> save
OK

执行save命令，会立即执行一次RDB。该命令会使用主进程执行RDB，从而阻塞其他所有命令。

Redis是单线程的，所以执行save命令时整个服务会阻塞，不能继对外提供请求，数据量小的话肯定影响不大，数据量大的时候就相当于停机很长一段时间。

2）执行bgsave命令

127.0.0.1:6379> bgsave
Background saving started

执行bgsave命令，可以异步执行RDB，会开启一个独立进程完成RDB，主进程可以继续处理用户请求，不受影响。

3）Redis停机时

Redis停机时会执行一次save命令，实现RDB持久化。

4）触发RDB条件时

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 禁用RDB
save ""

# 3600秒内，至少1个Key被修改时执行RDB
# 300秒内，至少100个Key被修改时执行RDB
# 60秒内，至少10000个Key被修改时执行RDB
save 3600 1 300 100 60 10000

# 是否压缩，默认yes
# 建议改为no以避免消耗CPU，但相应占用磁盘空间会增加
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb

# 文件保存的路径目录（默认是 ./）
dir /var/lib/redis

达到触发条件时，Redis会自动执行bgsave命令进行异步RDB。 而执行RDB后，可以在/var/lib/redis目录下看到RDB文件：

ll
total 8
-rw-r--r--. 1 root root  88 Apr 10 11:38 dump.rdb
-rw-r--r--. 1 root root 677 Apr 10 11:38 redis.log

5.1.1.2 bgsave原理

bgsave命令的原理是：fork() + Copy-On-Write。

fork()

fork()是Unix和Linux这种操作系统的一个api，而不是Redis本身的api。其特点有：

（1）fork()用于创建一个子进程，注意是子进程，不是子线程。
（2）fork()出来的子进程共享其父进行的内存数据，但仅仅是共享创建完成那一时刻的内存数据，后期主进程修改数据对子进程不可见，子进程修改的数据对主进程也不可见。
（3）子进程挂了，对主进程完全没影响，它依然可以对外提供服务；但是主进程挂了，子进程也必须跟随一起挂。
（4）主进程和子进程共享内存空间，但为什么它们之后对内存数据的修改操作对彼此不可见呢？答案是采取了copy-on-write技术。

Copy-On-Write（写时复制技术）

如上图所示，主进程fork()出子进程之后，主进程中的所有内存页表的权限都会被设为read-only，然后子进程的地址空间指向主进程，这也就是实现了主进程内存空间的共享。

当主进程执行读操作时，直接访问共享内存；当主进程执行写操作时（子进程只负责RDB，不会有写操作），CPU会检测到要操作的内存页表是read-only的，于是触发页表异常中断（page-fault），进行一个中断例程。

在中断例程中，CPU会把异常页表复制一份（这里仅仅复制异常页表，也就是要修改的那个数据页表，而不是内存中的全部数据），于是主、子进程各自持有独立的一份页表，主进程继续修改自己的那一份，子进程继续读取原来那份read-only的页表。

5.1.2 AOF持久化

5.1.2.1 AOF原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

5.1.2.2 AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

# AOF记录的频率
# 表示每执行一次写命令，立即记录到AOF文件
# appendfsync always
# 写命令执行完先放入AOF缓冲区，然后每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
# appendfsync no

AOF记录的频率三种策略的对比如下：

AOF的作用如下例：

127.0.0.1:6379> set test:name aaaa
OK

此时/var/lib/redis目录下创建了AOF相关目录及文件：

cd /var/lib/redis/
ls
appendonlydir  dump.rdb  redis.log

cd appendonlydir/
ll
total 12
-rw-r--r--. 1 root root 88 Apr 10 13:11 appendonly.aof.1.base.rdb
-rw-r--r--. 1 root root 61 Apr 10 13:11 appendonly.aof.1.incr.aof
-rw-r--r--. 1 root root 88 Apr 10 13:11 appendonly.aof.manifest

more appendonly.aof.1.incr.aof
$3
set
$9
test:name
$4
aaaa

5.1.2.3 AOF文件重写

AOF文件会记录每一个写命令，即使是对同一个Key的多次写操作也会全部记录下来，因此文件大小比RDB文件大得多。但是对同一个Key的多次写操作中，只有最后一次写操作才是有意义的，因此AOF将对同一个Key的全部写操作都记录下来的意义不大。

通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

Redis也会在触发阈值时自动重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

5.1.3 RDB和AOF的对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

5.2 Redis主从

5.2.1 搭建主从结构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

由上图可知，我们准备搭建的结构包含三个节点：一个主节点，两个从节点。我们可以在同一台虚拟机中开启3个不同端口的Redis实例来模拟主从集群。

其搭建步骤如下：

1）在/usr/local/redis目录下创建3个目录，名字分别是7001、7002、7003

2）分别拷贝配置文件redis.conf到这3个目录下

cp /root/redis-7.2.4/redis.conf /usr/local/redis/7001
cp /root/redis-7.2.4/redis.conf /usr/local/redis/7002
cp /root/redis-7.2.4/redis.conf /usr/local/redis/7003

3）修改3个目录下的配置文件（以7001为例，7002、7003类推）

# 关闭AOF
appendonly no

# 开启RDB
# save ""
save 3600 1 300 100 60 10000

# 修改RDB文件保存路径
dir /var/local/redis/7001

# 修改端口
port 7001

要将7002、7003实例配置为从节点，还需要在7002、7003的配置文件中增加两行配置：

# 配置为从节点，主节点的IP为192.168.146.128，端口为7001
slaveof 192.168.146.128 7001
# 配置主节点的密码（未设置密码时不需要）
masterauth 123321

4）启动3个实例

/usr/local/bin/redis-server /usr/local/redis/7001/redis.conf
/usr/local/bin/redis-server /usr/local/redis/7002/redis.conf
/usr/local/bin/redis-server /usr/local/redis/7003/redis.conf

5）查询集群状态

redis-cli -p 7001 -a 123321

至此，Redis主从集群搭建完成。

另外，对于开启主从关系，有临时和永久两种模式：

永久模式：在redis.conf中添加一行配置：slaveof <masterip> <masterport>，即上面使用的模式。

临时模式：使用redis-cli客户端连接到redis服务后，执行slaveof <masterip> <masterport>命令，这种模式在Redis重启后失效。

6）主从集群测试

利用redis-cli连接7001：

127.0.0.1:7001> set test:master 7001
OK
127.0.0.1:7001> get test:master
"7001"

利用redis-cli连接7002：

127.0.0.1:7002> set test:slave1 7002
(error) READONLY You can't write against a read only replica.
127.0.0.1:7002> get test:master
"7001"

利用redis-cli连接7003：

127.0.0.1:7003> set test:slave2 7003
(error) READONLY You can't write against a read only replica.
127.0.0.1:7003> get test:master
"7001"

由测试结果可知，只有在7001这个master节点上可以执行写操作和读操作，7002和7003这两个slave节点只能执行读操作。

5.2.2 主从数据同步原理

5.2.2.1 全量同步

主从节点第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝被slave节点。 其流程如下：

由上图所示，全量同步主要有三个阶段：

1）第一阶段：slave节点请求数据同步，master节点判断是否是第一次同步，如果是第一次同步则返回master节点的数据版本信息，slave节点保存版本信息；
2）第二阶段：master节点执行bgsave命令，生成RDB文件，并记录RDB期间的所有命令到repl_baklog中，然后将RDB文件发送给slave节点，slave节点收到后清空本地数据，加载RDB文件；
3）第三阶段：master节点继续发送到repl_baklog中保存的命令，slave节点收到后执行这些命令。

这里有一个问题：master如何得知salve是第一次请求数据呢？

在解答之前，先来了解两个概念：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。
offset：偏移量，随着记录在repl_baklog中的命令数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset，如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

一个节点在变成slave之前，也算一个master节点，也有自己的replid。在与master建立连接时，要发送自己的replid。如果master判断发现slave送过来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

同步完成后，master会将自己的replid和offset都发送给这个slave，slave保存这些信息，以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。那么全量同步的流程可以进行如下优化：

5.2.2.2 增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输给slave，成本是比较高的。因此除了第一次做全量同步，其它大多数时候master与slave都是做增量同步。

增量同步就是只更新master与slave存在差异的部分数据，其流程如下图：

由上图所示，增量同步主要有两个阶段：

1）第一阶段：slave节点请求数据同步，发送replid和offset，master节点收到后判断replid是否一致，如果一致说明要进行增量同步，回复continue；
2）第二阶段：master节点去repl_baklog中获取offset后的命令，并发送给slave节点，slave节点收到后执行这些命令，即完成了增量同步。

那master怎么知道slave与自己的数据差异在哪里呢？很明显就是依靠repl_baklog文件，该文件会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。

repl_baklog文件是一个固定大小的环形数组，也就是说下标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。