文章目录

• 一、RDB（Redis DataBase）
• 二、AOF（Append Only File）
• 三、配置文件选项解析
• 四、RDB与AOF优劣与分析
• • 1.RDB优劣
  • 2.AOF优劣
  • 3.二者选择

一、RDB（Redis DataBase）

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

        Redis的自动保存为BGSAVE操作，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，用二进制压缩存储（binlog）。整个过程，主进程是不会进行任何IO操作的。这就确保了极高的性能。如果需要大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更高效。RDB的缺点是最后一次持久化后的数据可能丢失。redis默认使用RDB。

自动触发机制：
        在配置文件中我们可以看到改字段，其含义为在900秒内存在1次修改时，自动触发BGSAVE。后面含义与此类似。

        持久化产生的默认文件名为dump.rdb

注意：

• 一般来说，在生产环境很少执行 SAVE操作，SAVE直接调用rdbSave，阻塞Redis主进程，直到保存完为止，在主进程阻塞期间，服务器不能处理客户端任何请求。所以一般使用BGSAVE异步地执行，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。如果负责保存数据的后台子进程不幸出现问题时，SAVE可以作为保存数据的最后手段使用。
• 如果执行shutdown命令关闭服务器，会在后台执行save命令对数据进行持久化。使用shutdown nosave则不会产生该文件
• 使用flushall命令清除也会产生dump.rdb文件，但其内容为空

        如果要恢复rdb文件，只需要将rdb文件放在redis启动目录即可，redis启动时就会自动检查dump.rdb 恢复其中的数据，可使用config get dir 查看dump.rdb文件读取位置，也可在配置文件中自行配置。

二、AOF（Append Only File）

        将我们所有的命令全都记录下来（读操作不记录），history，恢复时就把这个文件中的命令全部执行一遍。（默认不开启AOF功能，若其与RDB同时开启，优先使用AOF，因为其恢复数据更全）
        以日志形式来记录每个写操作，redis会将每一个收到的写命令都通过write函数追加到文件中（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构造数据，换而言之，redis重启后就会将该文件中的内容，将写指令从头到尾执行一次以完成数据恢复工作。

自动触发机制：
        AOF也有三种触发机制：每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好。每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失。不同步no：从不同步

        持久化产生的默认文件名为appendonly.aof

文件重写：
        AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了BGREWRITEAOF命令主动进行重写，也可以在文件超过64mb（默认）时也会自动重写。rewrite会像replication一样，fork出一个子进程，创建一个临时文件，遍历数据库，将每个key、value对输出到临时文件。输出格式就是Redis的命令，但是为了减小文件大小，会将多个key、value对集合起来用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中，rewrite成功后这些操作也会复制到临时文件中，在最后临时文件会代替AOF文件。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

三、配置文件选项解析

1.snapshotting快照 rdb配置

save 900 1 #若900秒内，至少有一个key进行了修改，就进行持久化
save 300 10 #同上
save 60 10000 #同上，高并发

stop-writes-on-bgsave-error yes 
#持久化出错，redis是否停止接收数据，使用户意识到数据并未正确持久化到磁盘上。

rdbcompression yes
#对于存储到磁盘中的快照即dump.rdb，可以设置是否进行压缩存储。

rdbchecksum yes 
#在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

dbfilename yes 
#设置快照的文件名，默认是 dump.rdb

dir ./
#rdb文件保存的目录，不能是文件名

2.append only模式 aof配置

appendfsync everysec #同步
#always 每次修改都会sync，消耗性能
#everysec 每秒执行一次sync，如果宕机，则会丢失这一秒数据
#no 不同步，这时候操作系统自己同步数据，速度最快

no-appendfsync-on-rewrite no  
#默认为no是最安全的方式，不会丢失数据，但在大量磁盘操作时会出现阻塞问题的问题。
#若设置为yes不会执行磁盘操作，只是写入了缓冲区，因此不会造成阻塞（因为没有竞争磁盘），但若此时redis挂掉，在linux的默认设置下，最多会丢失30s的数据。

auto-aof-rewrite-percentage 100 
#文件的大小超过基准百分之多少后触发bgrewriteaof。
#默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。

auto-aof-rewrite-min-size 64mb 
#当文件大小超过64mb时候就会重写aof文件

四、RDB与AOF优劣与分析

1.RDB优劣

（1）优势

1. RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑，非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

（2）劣势

1. 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2. 当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，**父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

2.AOF优劣

（1）优势

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
2. AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
3. AOF日志文件即使过大的时候，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。同时也不会影响客户端的操作。
4. AOF对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
5. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

（2）劣势

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

3.二者选择

        根据自己需求，是否愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。在两者同时启用时，AOF的优先级更高，因为其保存的数据完全11加完整。
性能建议：

1. 只做缓存，如果希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
2. 因为RDB文件只做后备用用途，建议只在Slave上持久化RDB文件，且只要15分钟备份一次就够了，只保留save 900 1这条规则
3. 如果开启 AOF，好处是在最恶劣的情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认64M太小了，可以设置到5G以上，默认超过原大小100%大小重写可以改到适当数值
4. 如果不关闭 AOF，仅靠Master-Slave Replication（主从复制）实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时宕机，如断电，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。