Redis的持久化方式RDB和AOF

ゞ浴缸里的玫瑰 2022-05-17 00:24 282阅读 0赞

## 一、 RDB ##

*  是什么：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，父进程是不用进行任何IO操作的，使Redis最大性能化。
 *  持久化配置：

save <seconds> <changes>
         秒钟       改变次数
    
    默认配置：
    save 900 1            在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    save 300 10           在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    save 60 10000         在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
    
    如果启用如上的快照（RDB），在一个存盘点之后，可能磁盘会坏掉或者权限问题，导致Redis不能继续工作那么可以更改Redis默认配置：
    stop-writes-on-bgsave-error yes 为 stop-writes-on-bgsave-error no

*  rdbcompression yes:是否将字符串用LZF压缩到.rdb 数据库中，如果想节省CPU资源可以将其设置成no，但是字符串存储在磁盘上占用空间会很大，默认是yes。
 *  rdbchecksum yes：rdb文件的校验，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
 *  禁用：配置文件中【save ''】，不要设置任何指令或者给save传入一个空字符串参数。用下面两种命令进行即时备份。

（1）save：只管保存，其它不管，全部阻塞。
    
    （2）bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取 
        最后一次成 功执行快照的时间。

*  恢复：将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。CONFIG GET dir获取目录。
 *  dump文件损坏修复：redis-check-dump --fix
 *  优势：

（1）RDB是Redis数据的一个非常紧凑的单文件，非常适合备份。例如，您可能希望在最近24小时内
        每小时归档您的RDB文件，并且每天保存RDB快照有效期为30天。这使您可以轻松的保存不同版本
        的备份以防止发生灾难。
    （2）RDB非常适合灾难恢复，可以将单个压缩文件传输到远端数据中心，或者转移到其它存储介质上。
    （3）RDB最大限度地提高了Redis的性能，因为Redis父进程唯一需要做的事就是复制一份子进程，然后由子进程 
        完成持久化工作。父实例永远不会执行磁盘I/O或类似操作。
    （4）与AOF相比，如果数据集很大，RDB的启动效率会更高。

*  缺点：

（1）如果想最大限度保持数据的高可用或者完整，RDB不是个很好的选择，因为在最后一次备份之前如果
        发生宕机，那么这段时间内的诗句将丢失。
    （2）RDB经常需要fork子进程才能将数据持久存储在磁盘上。如果数据集很大，Fork可能会很耗时，如果
        数据集非常大且CPU性能不佳，可能会导致Redis停止服务客户端几毫秒甚至一秒钟。

## 二、 ROF ##

*  是什么：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
 *  持久化配置：

（1）开启：appendonly no 改为 appendonly yes
    （2）appendfilename "appendonly.aof" AOF默认文件名，可根据需要更改。
    （3）在Redis的配置文件中存在三种同步方式，它们分别是：
         --appendfsync always     每次有数据修改发生时都会写入AOF文件。
         --appendfsync everysec   每秒钟同步一次，该策略为AOF的缺省策略。
         --appendfsync no         从不同步。高效但是数据不会被持久化。

*  恢复：重新启动服务即可。CONFIG GET dir获取目录。
 *  AOF文件损坏修复：redis-check-aof --fix
 *  rewrite:

（1）是什么：AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的
         大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可
         以使用命令bgrewriteaof。
    （2）原理：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再renam
         e)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof
         文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
    （3）触发机制：
             auto-aof-rewrite-percentage 100   超过原文件大小百分之百 
             auto-aof-rewrite-min-size 64mb    文件大小超过64MB
    （4）no-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。

*  优势：

（1）使用AOF使数据安全性更高：您可以使用不同的同步策略：每秒同步、每次更改同步、不同步。例如使用默认 
         同步策略，即每秒同步，写入性能仍然很好（同步使用后台线程执行，当进程中没有同步操作时主线程将会 
         尽可能的执行写入。）但是您只能丢失一秒的写入。
    （2）AOF日志采用的是append模式，因此如果是停电或者宕机,也不会损坏文件。即使日志由于某种原因（磁盘已 
         满或其他原因）写到一半也没关系，可以使用redis-check-aof工具轻松修复它。
    （3）当Redis太大时，Redis能够在后台自动重写AOF。重写是完全安全的，因为当Redis继续附加到旧文件时， 
         使用创建当前数据集所需的最小操作集生成一个全新的文件，并且一旦第二个文件准备就绪，Redis备份
         将切换至这个新文件上。
    （4）AOF以一个接一个的易于理解和解析的格式包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使 
         您使用一个错误的命令FLUSHALL清除了所有数据，如果在此期间未执行日志重写，您仍然可以保存数据，只 
         需停止服务器，删除最新命令，然后重新启动Redis。

*  缺点：

（1）AOF文件通常比同一数据集的等效RDB文件大。
    （2）根据确切的同步策略，AOF可能比RDB慢。通常将每秒同步策略的性能仍然非常高，并且在禁用同步，
         即使在高负载的情况下，它也应该与RDB一样快。在大量写入的情况下，RDB仍能够提供最大延迟的
         更多保证。
    （3）在过去，我们在一些特殊命令中遇到了罕见错误（例如，有一个涉及阻塞命令，如BRPOPLPUSH）导
         致生成的AOF在重新加载时不会重现完全相同的数据集。这在RDB中几乎不可能出现这种错误。

*  ### 怎么用： ###

（1）通常的建议是您应该开启两种持久方法，如果您希望它能够像PostgreSQL一样为您提供安全保障。两种方式共存时，先加载AOF。

（2）如果你非常关心你的数据紧凑型，允许在发生灾难时丢失几分钟数据，可以单独使用RDB。

（3）不建议单独使用AOF。

*  ### 性能建议： ###

（1）因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

（2）如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

（3）如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构