NOSQL Redis 数据持久化

查看redis 版本

Redis的配置文件

修改dump.rdb 默认的文件名和默认存储的路径

Redis 数据持久化

1. 快照方式（RDB，Redis DataBase） 全量的 在指定的时间间隔能对你的数据进行快照存储。
2. 文件追加方式（AOF，Append only File）增量
   记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
3. 混合持久性方式( redis 4 默认方式)

RDB 快照方式

实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写道磁盘上，也就是快照。即使出现宕机，快照也不会丢失，数据的可靠性得到保证，快照文件是RDB文件(dump.rdb)。

①在指定的时间间隔内将内存中的数据集快照写入磁盘，即Snapshot内存快照，他恢复是再将硬盘快照文件直接读回内存里。

②redis的数据都在内存中，保存备份时它执行的是全量快照，即把内存所有数据存入磁盘。

③RDB保存的文件是dump.rdb。

触发策略

①手动触发两个命令
手动save命令：通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。save 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server
进程阻塞期间，Redis不能处理任何读写请求，无法对外提供服务。线上禁止使用
手动bgsave命令：通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命 令的是，正如该命令的名称一样，background save，后台运行 save。bgsave 命令会使服务器进程 redis-server
会fork一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程中，不会阻塞 redis-server
进程对客户端读写请求的处理。

②自动条件触发的本质：是 bgsave 命令的执行。
用户通过在配置文件中做相应的设置后，Redis会根据设置信息自动调用bgsave命令执行。
对于 RDB 持久化而言，我们一般都会使用 BGSAVE 来持久化，毕竟它不会阻塞服务器进程。
在 Redis 的配置文件，有提供设置服务器每隔多久时间来执行 BGSAVE 命令。
Redis 默认是如下配置：
save 900 1 // 900 秒内，对数据库至少修改 1 次。下面同理
save 300 10
save 60 10000
只要满足其中一种情况，服务器就会执行 BGSAVE 命令。

优势：
①适合大规模的数据恢复、 已经dump.rdb 是压缩的，恢复比较快
②按照业务定时备份、
③对数据完整性和一致性要求不高、 不秒级别备份的
④RDB文件在内存中的加载速度比AOF快。

劣势：
①在一定间隔时间做一次备份，如果redis意外宕机，就丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失；
②内存数据的全量同步，如果数据量太大会导致I/O严重影响服务性能
③RDB依赖于主进程的fork，在更大数据集上，可能导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致膨胀两倍。需要考虑。

RDB 持久化配置

# 时间策略
save 900 1
save 300 10
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

rdb对应配置参数
rdbcompression yes
默认是yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
stop-writes-on-bgsave-error yes
默认yes
如果配置成no，表示你不在乎数据不一致或者有其它的手段发现和控制这种不一致，
那么在快照写入失败时，也能确保redis继续接受新的写请求，
rdb-del-sync-files no
在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。
rdbchecksum yes
默认yes
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

AOF(Append Only File)持久化

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件，但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。

默认情况下，redis没有开启AOF，开启配置：appendonly yes。

appendfsync 文件同步策略 **
appendfsync Always：同步写回，每个写命令执行完立刻同步的将日志写回磁盘**。可靠性高，数据基本不丢失
appendfsync everysec：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘。性能较好
appendfsync no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。性能好

AOF 重写机制

Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
或者
可以手动使用命令bgrewriteaof来重写

AOF持久化配置

# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

RDB、AOF 混合

同时关闭 RDB、AOF

#禁止 rdb
save “”
禁止aof
appendonly no