Redis核心技术-持久化-RDB生成&恢复

  RDB(Redis Database) 内存快照，就是指内存中的数据在某一个时刻的状态记录。

  和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。

  但内存快照也并不是最优选项

RDB配置

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
# 配置格式
# save <seconds> <changes>
#距离上一次生成快照操作900秒后发送1次写操作，执行生成快照
save 900 1
#距离上一次生成快照操作300秒后发送10次写操作，执行生成快照
save 300 10
#距离上一次生成快照操作60秒后发送10000次写操作，执行生成快照
save 60 10000

#持久化失败后, 是否停止写rdb
stop-writes-on-bgsave-error yes

#保存rdb文件时, 是否校验
rdbchecksum yes 

#是否压缩rdb文件
rdbcompression yes

#rdb文件名称
dbfilename dump.rdb

#rdb文件是否删除同步锁
rdb-del-sync-files no

#快照保存目录
dir ./

也就是说，距离上一次写入操作多少秒后至少发生了多少次写入次数，则保存一次db。需要时间和写次数同时满足才执行生成快照操作。

如何生成快照

save命令

命令执行：

> save
OK

执行save时在主线程中执行，会导致阻塞。

生产环境不要执行 SAVE 命令，因为这会阻塞所有其它的客户端。可以使用 BGSAVE 代替。

bgsave命令

命令执行：

> bgsave
Background saving started

bgsave时创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

主线程的确没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。

为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。

恢复快照

redis在启动是根据dump.rdb（前面配置快照文件）恢复key-value到内存。

但是如果没save配置的时间内达到写操作次数redis便宕机，那么上次生成快照后的写操作key由于没有生成快照将会丢失。

1.查看当前快照：

$ ll |grep dump.rdb
-rw-r--r-- 1 Administrator 197121     139  1月 29 16:07 dump.rdb

2.执行写操作

> get test-key
test-val
> get tk
null
> set tk val1
OK
> get tk
val1

3.关闭redis服务

4.查看key是否恢复

> 127.0.0.1@6379 connected!
> get tk
null
> get test-key
test-val

优缺点

优点

1.RDB基于某个时间点内存的快照持久化，不需要主进程再操作Key时记录操作日志；
2.RDB是一个非常紧凑(compact)的文件，大量数据恢复时比较快

缺点

1.bgsave运行时要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
2.在一定间隔时间做一次备份，会丢失最后一次快照后的所有修改