Redis持久化策略（RDB/AOF）及选型

Redis持久化策略（RDB/AOF）及选型

1. Redis持久化策略

Redis持久化的意义：防止服务或系统宕机导致数据丢失。

Redis提供了两种持久化策略：RDB（Redis DataBase）、AOF（Append Only File）。

• RDB：默认的持久化策略，将Redis存储的数据直接生成快照并进行持久化。
• AOF：保存Redis执行过的指令记录，Redis重启时直接重新执行一遍指令即可恢复数据。

注：RDB和AOF可以同时使用，也可以都不使用。在前者的情况下Reids会优先使用AOF恢复数据（完整度高），后者情况下Redis将变成纯内存数据库（断电即失）。

RDB（Redis DataBase）

RDB是Redis默认的持久化策略，会将Redis某一时刻的数据快照持久化到磁盘中。

RDB策略在持久化过程中会将数据写入一个临时文件，当临时文件完全写入完毕后再替换上一份持久化生成的RDB文件。具体地，Redis会派生（fork）出一个子进程进行上述持久化操作，而不影响主进程正常的IO操作，这使得Redis在派生出子进程后，持久化操作几乎不会影响主进程的性能。

在进行大规模数据恢复时，RDB比AOF更加高效，但是RDB会丢失上一次持久化后的全部数据，因此不适合数据完整性敏感的应用场景。（比如16：05服务挂了，上一次备份是16：00，这中间五分钟的数据就全丢失了）。

AOF（Append Only File）

AOF策略会将Redis执行过的指令记录下来，需要恢复数据时直接顺序执行一遍。

默认的AOF持久化策略是每秒fsync一次（把缓存中的写指令记录到磁盘中），这个频率是性能和安全性比较均衡的节点，即既不对处理性能产生较大影响，在服务宕机时也只会丢失不到一秒的数据。

AOF文件采取的是追加方式，这就导致不处理的话AOF文件会越来越多，Redis提供了AOF文件重写（rewrite）机制，当AOF文件大小超过阈值时，Redis会压缩AOF的文件内容，只保留可以恢复当前数据的最小指令集。

AOF文件重写也是派生子进程先写临时文件再替换，同时主进程的写指令会存进缓冲区，等重写完成后追加到新AOF文件里，最后替换原文件。

2. 选型

省流：官方建议一起用

RDB：

• 优势：同数据规模下数据文件小，恢复数据快。
• 劣势：需要定时持久化，服务宕机时会丢失上一次持久化到当前的数据，数据量可能很大。

AOF：

• 优势：服务宕机时丢失的数据少；管理员误操作时挽回的空间大（毕竟存了完整的指令记录）。
• 劣势：同数据规模下数据文件更大，恢复更慢；每秒fsync写入硬盘，如果硬盘IO性能差，会阻塞父进程，同理，AOF文件重写时主进程会把指令存到缓冲区，最后写盘时会阻塞主进程。

3. 开启AOF持久化策略

• 找到Redis配置文件，有一行appendonly，默认是no，改成yes：

#设置为yes
appendonly yes
#存储的文件
appendfilename "appendonly.aof" 

• 设置触发机制

AOF三种触发机制，always，everysec，no，默认是everysec

#同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
# appendfsync always
#异步每秒记录一次，如果一秒内宕机，有数据丢失
appendfsync everysec
#从不同步
# appendfsync no

• AOF重写策略

bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形。
Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewritev。
auto-aof-rewrite-min-size最开始的AOF文件必须要触发这个文件才触发，后面的每次重写就不会根据这个变量了。该变量仅初始化启动Redis有效。

#如果有延迟问题，设置为“yes”。否则no
#从耐用性的角度来看，“no”是最安全的选择。
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb