Redis持久化操作

Redis提供了两种持久化方式RDB（Redis Database）和AOF（Append Of File）

一、RDB（Redis Database）

1.1 RDB是什么？

在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存中。

2.1 Redis备份

Redis会单独创建一个子进程来进行持久化，会先将数据存到一个临时的文件中，待持久化过程结束后，再用临时文件替换上次持久化的文件。整个持久化过程中，主进程不进行任何得到IO操作，这样就确保了极高的性能。如果需要进行大规模的数据恢复，且对数据恢复的完整性不那么敏感，那么使用RDB比AOF方式更加高效。

RDB的缺点是最后一次持久化可能会造成数据丢失。

2.2 RDB的优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高，更适合使用
• 节省磁盘空间
• 恢复速度快

二、AOF（Append Only File）

AOF (Append Only File) 持久化默认是关闭的，通过将 redis.conf 中将 appendonly no，修改为 appendonly yes 来开启AOF 持久化功能，如果服务器开始了 AOF 持久化功能，服务器会优先使用 AOF 文件来还原数据库状态。只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态

2.1、AOF是什么？

AOF持久化功能提供了一种更为可靠的持久化方式，AOF是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来，只追加文件但不可以改写文件

当RDB和AOF同时开启时，系统默认会取AOF的数据（AOF的数据不会丢失）

2.2 AOF持久化流程

1. 客户端请求写命令会被append追加到AOF缓冲区内；
2. AOF缓存区根据AOF持久化策略【always，everysec，no】将操作同步到磁盘的AOF文件中
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件进行rewrite重写，压缩AOF文件容量
4. Redis服务重启时，会重写加载AOF文件中的写操作达到数据恢复的目的。

2.3 AOF异常恢复

当AOF文件损坏，通过/usr/local/bin目录下的命令 redis-check-aof --fix appendonly.aof进行恢复

2.4 AOF同步频率（appendfsync）设置

appendfsync
always	始终同步，每次Redis的写入都会立即记入日志（性能较差但数据完整性比较好）。
everysec	每秒同步，每秒记入日志一次，如果宕机，本秒数据可能丢失。
no	不主动同步，把同步时机交给操作系统。

2.5 Rewrite压缩

AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

优点

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文件，通过操作AOF文件，可以处理误操作

缺点

• 比RDB占用更多的磁盘空间
• 恢复备份速度慢
• 每次写都同步，有一定的性能压力