Redis拔高篇——Redis的持久化

Redis持久化

为什么Redis存在持久化

在我的windows下，使用完Redis之后关闭，数据仍然存在，甚至在过了几个月后redis中的数据仍然存在。没错，当我们在本地装了redis，并且在redis中写了数据，重启计算机后数据依然会存在。

但是学习Redis的时候，使用了Linux，我发现了一个问题，打开一次redis-server，存储、获取数据都是正常的，但是关闭之后重启，数据全都丢了，我的妈呀，what happened？

后来查询了很多博客，我明白了，由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。所以，redis如果没有做持久化，在重启redis后，数据会丢失。

RDB

RDB基本介绍

RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

RDB启动方式——手动保存

在数据库操作的时候手动输入save，进行数据库的一次保存。

配置文件的内容：（配置文件的位置：redis-4.0.0/conf/redis.conf）

# 指定启动的端口
port 6379
# 设置是否后台启动
daemonize yes
# 设置日志文件存的文件的名称
logfile "6379.log"
# 设置.rdb文件的存储路径
dir /usr/local/redis/redis-4.0.0/data
# 设置rdb文件的名称
dbfilename dump.rdb

然后data目录下生成的dump.rdb文件当中的数据如下：（正常人应该都看不懂，但是部分的东西还是看的懂的，最起码数据xiaobai存在）

但是我们不能保证每次都会把输入的数据存储下来，在数据量大的时候难免会忘记save数据， 那么有没有一种方式可以把数据保存到磁盘，这样我们的注意力就可以都放在数据上了。

RDB启动方式——save自动执行配置

• 配置：save second changes
• 作用：满足限定时间范围内key的变化数量达到指定数量即进行持久化
• 参数：second：监控时间范围 | changes：监控key的变化量A
• 位置：在conf文件中进行配置
• 范例：
  save 900 1
  save 300 10
  save 60 10000
  

配置文件内容

# 指定启动的端口
port 6379
# 设置是否后台启动
daemonize yes
# 设置日志文件存的文件的名称
logfile "6379.log"
# 设置.rdb文件的存储路径
dir /usr/local/redis/redis-4.0.0/data
# 设置rdb文件名称
dbfilename dump.rdb
# save <second> <changes>
save 10 2

second是时间限制，changes是改变的次数，这个配置的含义就是在规定的时间内，数据改变的次数达到changes，自动执行一次持久化，来看一下演示：

save配置原理

设置数据

执行结果

上面的图证明，只有在对数据库当中的数据进行更改的时候，才执行持久化操作，像get这种查询语句，对数据没有一点儿影响的操作是不会触发save操作的。像是重写，修改，增加字段这些操作，对redis当中的数据产生了影响，所以在一定的时间内发生指定次数的修改，就会执行save操作。

思考（自己的理解，希望大家帮忙纠正）

1、当固定时间内，发生修改的次数不够怎么办？
答：不满足就继续往下计时，直到次数够了，执行save操作，把数据写入rdb文件，计时时间归零，继续下一次计时
2、当固定的时间内，发生的次数过多怎么办？
答：达到指定的次数，执行save操作，计时归零

继续想一个问题，因为redis是单线程，那么也就是说redis的各种操作和持久化是在同一个线程当中执行的，那么如果访问量特别高，花费在IO上的时间也是相当多的，效率也是低的，那么有没有另外一种方式，可以提高redis的利用效率呢？我们自己想的话，可能想到单开一个线程进行IO读写，这样持久化的操作就不会占用主线程，利用效率也就提升上来了。

Redis的开发者也想到了这个问题，所以给持久化操作提供了一种新的方法。

RDB启动方式——bgsave后台执行

配置文件内容

# 指定启动的端口
port 6379
# 设置是否后台启动
daemonize yes
# 设置日志文件存的文件的名称
logfile "6379.log"
# 设置.rdb文件的存储路径
dir /usr/local/redis/redis-4.0.0/data
# 设置rdb文件名称
dbfilename dump.rdb
# rdb存储到本地是否压缩，默认yes，采用LZF压缩
rdbcompression yes
# 是否进行RDB文件格式校验，写文件和读文件的时候都进行
rdbchecksum yes 
# save <second> <changes>
save 10 2

代码执行样例：

bgsave执行流程

1、输入bgsave指令之后，向redis数据库发送
2、redis调度fork函数生成子进程，同时向客户端发送Background saving started信息
3、子进程找到一个时间执行，之后创建.rdb文件
4、子进程运行完毕，向父进程发送执行完毕消息

bgsave命令是针对save在大量的持久化时发生的阻塞问题做的优化。
学到这里redis内部所有涉及到RDB操作都可以采用bgsave的方式，save命令可以放弃使用。

RDB特殊启动形式

• 服务器运行过程中重启
  debug reload
• 关闭服务器时指定保存数据
  shutdown save

RDB总结

save和bgsave启动方式的对比

方式	save指令	bgsave指令
读写	同步	异步
阻塞客户端指令	阻塞	不阻塞
额外内存消耗	无	有
启动新进程	无	有

1、bgsave保存数据的时候，是单独开一个线程，所以是异步的
2、save的所有操作都是在一个进程当中执行的，保存数据的过程涉及到的IO操作会阻塞线程，让客户端发生延迟
3、save所有的操作都是在单独的线程之内，没有额外内存消耗；但是bgsave开一个新的线程，额外占用空间

RDB优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多
• 应用:服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
• Redis的众多版本中未进行RDB文件格式的版本统一， 有可能出现各版本服务之间数据格式无法兼容现象

注意

1、save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题，结果可能是灾难性的
2、save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
3、save配置启动后执行的是bgsave操作

AOF

AOF的概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

RDB的缺点

RDB虽然比较强大，但是也是存在一些不足的，现在再次总结一下：

• 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
• 大数据量下的IO性能较低
• 执行bgsave指令的时候，基于fork创建子进程，内存产生额外消耗
• 假如说服务器宕机了，那么子线程也会结束，数据就存在着丢失风险

AOF执行流程

1、在执行增加或者是修改字段操作之后，向redis发送这些指令
2、之后redis把这些指令写到AOF写命令刷新缓冲区当中，
3、同步缓冲区的数据到.aof文件当中

AOF写数据三种策略(appendfsync)

• always(每次)
  每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
• everysec (每秒)
  每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置在系统突然宕机的情况下丢失1秒内的数据
• no (系统控制)
  由操作系统控制每次同步到AOF文件的周期，整体过程不可控

叭叭叭说一堆，那到底是怎么操作呢？？别急，这不来了

AOF功能开启

• 配置
  appendonly yes| no
• 作用
  是否开启AOF持久化功能，默认为不开启状态
• 配置
  appendfsync | aIways I everysec I no
• 作用
  AOF写数据策略

配置文件内容

# 指定启动的端口
port 6379
# 设置是否后台启动
daemonize yes
# 设置日志文件存的文件的名称
logfile "6379.log"
# 设置.rdb文件的存储路径
dir /usr/local/redis/redis-4.0.0/data
# 是否开启aof持久化功能，默认是no
appendonly yes
# 指定aof写策略
appendfsync everysec

操作演示

生成的appendonly.aof文件的内容：

.aof文件把我们所有的操作都记录下来，但是思考一个问题，要是我进行下面这些操作：

127.0.0.1:6379> set name xiaohei
OK
127.0.0.1:6379> set name black
OK
127.0.0.1:6379> set name white
OK
127.0.0.1:6379> incrby age 1
(integer) 12
127.0.0.1:6379> incrby age 1
(integer) 13
127.0.0.1:6379> incrby age 1
(integer) 14
127.0.0.1:6379> incrby age 1
(integer) 15

对于这样的重复操作,appendonly.aof文件会怎样记录呢？查询一下：

上面的内容暂且不提，就光看最后的这几行数据，就知道incr的4次操作都记录下来了，其实也挺好，每一步的清清楚楚，但是这假如说我写一个统点赞数量的功能，那得记录多少条？文件可是相当大的，这让本来就不充足的服务器空间更加的紧紧巴巴，那么可不可以简化一下，比如说我incrby四次，之后aof文件记录的是incrby age 4，一条顶四条，那么aof文件所占用的空间就会大大减少。

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入 了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若千个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量,提高磁盘利用率
• 提高持久化效率,降低持久化写时间，提高lO性能
• 降低数据恢复用时，提高数据恢复效率

AOF重写规则

• 进程内已超时的数据不再写入文件
• 忽略无效指令,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令
  如del key1、hdel key2、srem key3、setkey4 111、set key4 222等
• 对同一数据的多条写命令合并为一条命令
  如lpush list1 a. lpush list1 b、Ipush list1c可以转化为: lpushlist1abc.
  为防止数据量过大造成客户端缓冲区溢出，对list. set. hash, zset等类型,每条指令最多写入64个元素

AOF手动重写

指令：bgrewriteaof
操作演示：（紧接着查看aof文件内容）

全都变成设置字段时候的状态，这就大大节省了存储空间。

AOF手动重写流程

1、输入bgrewriteaof指令之后，向redis数据库发送指令
2、redis调度fork函数生成子进程，同时向客户端发送Background append only file rewriting started信息
3、子进程找到一个时间执行，之后重写.aof文件
4、子进程运行完毕，向父进程发送执行完毕消息

AOF自动重写方式

既然RDB存在自动执行保存数据的bgsave，那么重写aof肯定也存在一个自动执行的方式。

• 自动重写触发条件设置
  auto-aof-rewrite-min-size size
  auto-aof-rewrite-percentage percent
• 自动重写触发比对参数(运行指令info Persistence获取具体信息)
  aof_current_size
  aof_base_size
• 自动重写触发条件
  aof_current_size>auto-aof-rewrite-min-size
  (aof_current_size - aof_base_size) / (aof_base_size) >= auto-aof-rewrite-percentage

那么稍微修改一下配置文件内容

# 指定启动的端口
port 6379
# 设置是否后台启动
daemonize yes
# 设置日志文件存的文件的名称
logfile "6379.log"
# 设置.rdb文件的存储路径
dir /usr/local/redis/redis-4.0.0/data
dbfilename dump.rdb
# rdb存储到本地是否压缩，默认yes，采用LZF压缩
rdbcompression yes
# 是否进行RDB文件格式校验，写文件和读文件的时候都进行
rdbchecksum yes 
# save <second> <changes>
save 10 2
# 是否开启aof持久化功能，默认是no
appendonly yes
# 指定aof写策略
appendfsync everysec
# 设置最小的自动重写aof文件的长度
auto-aof-rewrite-min-size 300
# 设置aof文件的名称
appendfilename appendonly-6379.aof

AOF重写流程（详细）

1、按照always配置，执行set指令的时候，主进程执行set指令，同时启动fork进程，子进程把set操作写到非重写.aof文件当中
2、按照everysec配置，当执行set指令的时候，主进程生成fork进程，同时执行set指令，fork新进程把set指令写到.aof缓冲区当中，当满足某个条件的时候，缓冲区当中的数据一并写到非重写.aof文件当中。
3、基于everysec开启重写，当执行set指令的时候，主进程生成fork进程，同时执行set指令，fork新进程把set指令写到.aof缓冲区和.aof重写缓冲区当中，aof缓冲区满足某个条件的时候，aof缓冲区当中的数据一并写到非重写.aof文件当中，当满足某个重写的条件的时候，aof重写缓冲区的内容重写.aof文件的内容。

4、执行bgrewriteaof重写指令的时候，主进程开启fork进程，同时返回bgwriteaof的提示信息，fork生成的子进程执行重写aof文件的操作，之后生成新的aof文件，最后和原来的aof文件进行合并替换。

上面写的aof重写缓冲区重写aof文件的时候，提供数据，生成新的aof文件，最后也是和原来的aof文件进行合并替换

总结：AOF和RDB的区别

我学到的东西都写到这篇博客当中了，现在总结一下这两种持久化的方式有哪些区别。

持久化方式	RDB	AOF
占用存储空间	小（存储数据集）	大(存储指令集)
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	根据策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

持久化方式RDB和AOF的选择

• 对数据非常敏感，建议使用默认的AOF持久化方案，就像根本不允许丢失数据或者只允许丢失很少一部分数据的项目，需要使用AOF进行持久化

• AOF持久化策略使用everysecond,每秒钟fsync一次。 该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0- 1秒内的数据。
  注意：由于AOF文件存储体积较大，且恢复速度较慢

• 数据呈现阶段有效性，建议使用RDB持久化方案

• 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的)，且恢复速度较快，阶段点数据恢复通常采用RDB方案
  注意：利用RDB实现紧凑的数据持久化会使Redis降的很低

综合比对

• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
• 灾难恢复选用RDB
• 双保险策略，同时开启RDB和AOF，重启后，Redis优先使用AOF来恢复数据，降低丢失数据的量