Redis学习（四） redis持久化操作——RBD和AOF

1 引言

redis是内存数据库，存在内存中的数据若是不进行存储也就是持久化操作，那么断电之后，内存中的数据就会丢失，所以在操作redis的时候我们需要了解其持久化操作

2 Reids持久化操作之RDB（Redis DataBase）

2.1 RDB原理

redis通过调用（fork）一个子进程来进行持久化操作。这个子进程会将数据先写入一个临时文件中去，等持久化操作结束之后，将会使用这个临时文件去替换旧的持久化文件。注意，这个子进程可以看做父进程的孪生兄弟（他们的所有数据包括环境变量都一模一样）。
通过RDB的持久化方式，主进程不需要进行IO操作，这样就保证了它的一个执行效率。

2.1.1 何时触发持久化操作？（何时fork子进程）

• 按照配置文件中对快照的配置规则来触发
• 关闭redisf服务时，且redis没有开启AOF机制时会触发
• 执行 flushall 命令清空数据
• 手动触发
  – save命令：阻塞redis的所有操作，直到RDB过程结束为止
  – bgsave命令：Redis会在后台异步进行快照操作，阻塞只发生在fork阶段，一般时间很短。

2.2 RDB方式的相关配置文件

 save "" #空字符串代表禁用快照

 save 3600 1 #在3600秒内若进行了至少1次操作就生成一份快照
 save 300 100 #在360秒内若进行了至少100次操作就生成一份快照
 save 60 10000 #在60秒内若进行了至少10000次操作就生成一份快照

stop-writes-on-bgsave-error yes #持久化过程中如果出错，redis是否继续工作

rdbcompression yes #是否压缩rdb文件，代价是耗费cpu资源

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

dir ./ #rdb文件的生成目录

2.3 RDB方式恢复数据

redis在启动时会自动读取其安装目录下的RDB文件，在读取RDB文件恢复数据完成之前，redis会一直处于阻塞状态

3 Reids持久化操作之AOF（Append Only File）

3.1 AOF原理

AOF能像日志一样详细记录下redis运行过程中的所有操作，并且是只能追加写入而不能修改的。所以以AOF方式进行持久化的原理就很容易理解了：在新的redis环境中重新执行所有操作指令已达到数据恢复的效果。

3.2 AOF方式的相关配置文件

ppendonly no #是否启用AOF方式，默认我们采用RDB方式

appendfilename "appendonly.aof" #生成的AOF文件文件名

#配置持久化策略
appendfsync *****
# no：不执行fsync，由操作系统保证数据同步到磁盘，速度最快。  
# always：每次写入都执行fsync，以保证数据同步到磁盘。
# everysec：每秒执行一次fsync，可能会导致丢失这1s数据。

No-appendfsync-on-rewrite #重写时是否启用appendfsync策略

Auto-aof-rewrite-percentage 100 #aof文件增长比例，指当前aof文件比上次重写的增长比例大小。

Auto-aof-rewrite-min-size 64mb #aof文件重写最小的文件大小(第一次触发重写时的文件大小）

3.3.1 AOF的重写机制

AOF 文件的体积在不断追加的过程中就会变得越来越大，这就会有一些问题，比如：redis服务器的存储压力以及增加AOF恢复数据的时间。当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，即创建一个新的AOF替代现有的AOF，新AOF文件是原有AOF文件的“精简版”，也就是说新的AOF文件剔除了旧AOF文件的冗余命令。

3.3.2 重写机制的原理

AOF文件大小达到阈值时，会fork出一条新进程来将文件重写（先创建个临时文件然后替换）。重写的过程中会直接读取数据库中的键值对进行记录，而不访问原有的AOF文件。

4 总结

AOF和RDB时redis的两种持久化方式，它们各有优缺点。RDB没有频繁的IO操作，性能好，但对数据的保存不具有实时性，不能保证数据的完整性；RBD文件相较于AOF占用空间更小，恢复数据载入更快。而AOF虽然能够详细记录数据但要频繁读写，牺牲了性能；AOF文件相较于RDB占用空间更大，恢复数据载入更慢且可能会因为文件损坏而出现潜在bug。
-注意：RDB与AOF同时使用时，数据库优先载入AOF文件来恢复原始的数据，因为AOF保存的数据更加完整