Redis

文章目录
前言
一、RDB
1、备份是如何进行的
2、持久化过程
3、触发方式
自动触发
手动触发
4、数据恢复
5、停止 rdb 持久化
6、rdb 优点和缺点
二、AOF
1、备份是如何进行的
2、持久化过程
3、开启设置
4、RDB 和 AOF 同时开启
5、AOF 启动 / 修复 / 恢复
6、AOF 同步频率设置
7、AOF 优点和缺点
总结
References
前言
由于 redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的 MySQL，Oracle 等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失.
redis 持久化是指在指定的时间间隔内将内存中的数据集快照 (snapshotting) 写入磁盘，恢复时是将快照文件读入内存 redis 提供了两种持久化方式

RDB(Redis DataBase)
AOF(Append of File)
一、RDB
1、备份是如何进行的
redis 会单独创建一个子进程 (使用 fork 函数) 来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效
RDB 的缺点是最后一次持久化后的数据可能丢失
注： fork 函数的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
2、持久化过程

3、触发方式
自动触发
手动触发
自动触发

save：这里是用来配置触发 redis 的 rdb 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如 “save m n”。表示 m 秒内数据集存在 n 次修改时，自动触发 bgsave（这个命令下面会介绍，手动触发 RDB 持久化的命令）

save 20 3 表示在 20 秒内如果至少有 3 个 key 发生变化，则保存
1
当然如果你只是用 Redis 的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save “”

stop-writes-on-bgsave-error：默认值为 yes。当启用了 RDB 且最后一次后台保存数据失败，Redis 是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果 Redis 重启了，那么又可以重新开始接收数据了。

rdbcompression ：默认值是 yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

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

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

dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。

手动触发
手动触发 Redis 进行 RDB 持久化的命令有两种：

1、save

该命令会阻塞当前 Redis 服务器，执行 save 命令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止。
显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis 提供了第二种方式。

2、bgsave

执行该命令时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是 Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。基本上 Redis 内部所有的 RDB 操作都是采用 bgsave 命令。

ps: 执行执行 flushall 命令，也会产生 dump.rdb 文件，但里面是空的.

4、数据恢复
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis 就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

5、停止 rdb 持久化
redis-cli config set save “”
1
6、rdb 优点和缺点
优点
1.RDB 是一个非常紧凑 (compact) 的文件，它保存了 redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2. 生成 RDB 文件的时候，redis 主进程会 fork () 一个子进程来处理所有保存工作，主进程不需要进行任何磁盘 IO 操作。
3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
缺点
1、RDB 方式数据没办法做到实时持久化 / 秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，如果不采用压缩算法 (主进程 fork 出子进程，其实是共享一份真实的内存空间，但是为了能在记录快照的时候，也能让主线程处理写操作，采用的是 Copy-On-Write（写时复制）技术，只有需要修改的内存才会复制一份出来，所以内存膨胀到底有多大，看修改的比例有多大)，频繁执行成本过高 (影响性能)
2、RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题 (版本不兼容)
3、在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改 (数据有丢失)
二、AOF
1、备份是如何进行的
以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

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

3、开启设置
AOF 默认不开启，需要将 appendonly 设置成 yes

PS:AOF 文件的保存路径，同 RDB 的路径一致

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

5、AOF 启动 / 修复 / 恢复
启动

AOF 的备份机制和性能虽然和 RDB 不同，但是备份和恢复的操作同 RDB 一样，都是拷贝备份文件，需要恢复时再拷贝到 Redis 工作目录下，启动系统即加载。

正常恢复

修改默认的 appendonly no，改为 yes

将有数据的 aof 文件复制一份保存到对应目录 (查看目录：config get dir)

恢复：重启 redis 然后重新加载

异常恢复

修改默认的 appendonly no，改为 yes

如遇到 AOF 文件损坏，通过 /usr/local/bin/redis-check-aof–fix appendonly.aof 进行恢复

备份被写坏的 AOF 文件

恢复：重启 redis，然后重新加载

6、AOF 同步频率设置
appendfsync always

始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis 不主动进行同步，把同步时机交给操作系统。

7、AOF 优点和缺点
优点

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

比起 RDB 占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别 Bug，造成恢复不能。

总结
官方推荐两个都启用；
如果对数据不敏感，可以选单独用 RDB；
不建议单独用 AOF，因为可能会出现 Bug；
如果只是做纯内存缓存，可以都不用。

References
RDB 持久化
————————————————
版权声明：本文为 CSDN 博主「rayzhang0225」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：blog.csdn.net/m0_43424329/article/...

本作品采用《CC 协议》，转载必须注明作者和本文链接