011 - Redis 的持久化

最新推荐文章于 2024-07-22 16:47:14 发布

难解的题

最新推荐文章于 2024-07-22 16:47:14 发布

阅读量60

点赞数

分类专栏： Redis 文章标签： redis nosql 数据持久化

本文链接：https://blog.csdn.net/weixin_53538819/article/details/115635433

版权

Redis 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

一、Redis 的持久化

redis 是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当 redis 所在服务器因某些原因发生宕机后，redis 数据库里的所有数据将会全部丢失。

为了解决这个问题，redis 提供了持久化功能——RDB和AOF（Append Only File）。

一、RDB（Redis DataBase）

RDB：是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载 dump.rdb 文件来恢复数据。

1.原理

Redis 会复制一个与当前进程一样的进程，其中新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，来进行持久化。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2.RDB保存的文件

RDB 保存的文件是 dump.rdb ,位置在Redis的启动目录。

Redis每次同步数据到磁盘都会生成一个 dump.rdb 文件，新的 dump.rdb 会覆盖旧的 dump.rdb 文件。

3.配置RDB 持久化策略

在 redis.conf 的快照配置中，配置RDB保存的策略：
- save ：配置复合的快照触发条件，即 Redis 在 seconds 秒内 key 改变 changes 次，Redis 把快照内的数据保存到磁盘中一次，如果要禁用Redis的持久化功能，则把所有的save配置都注释掉。
- stop-writes-on-bgsave-error：当 bgsave 快照操作出错时停止写数据到磁盘，这样能保证内存数据和磁盘数据的一致性，但如果不在乎这种一致性，要在bgsave 快照操作出错时继续写操作，这里需要配置为no。
- rdbcompression：设置对于存储到磁盘中的快照是否进行压缩，设置为yes时，Redis会采用LZF算法进行压缩；如果不想消耗 CPU 进行压缩的话，可以设置为 no，关闭此功能。
- rdbchecksum：在存储快照以后，还可以让Redis使用CRC64算法来进行数据校验，但这样会消耗一定的性能，如果系统比较在意性能的提升，可以设置为no，关闭此功能。
- dbfilename：Redis持久化数据生成的文件名，默认是dump.rdb，也可以自己配置。
- dir：Redis持久化数据生成文件保存的目录，默认是./即redis的启动目录，也可以自己配置。

save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./

在客户端执行 FLUSHDB 或者 FLUSHALL 或者 SHUTDOWN 时，也会把快照中的数据保存到 dump.rdb，只不过这种操作已经把数据清空了，保存的也是空文件，没有意义。

4.手动保存RDB快照

save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

由于save指令会阻塞所有客户端，所以保存数据库的任务通常由 BGSAVE 命令异步地执行，而save作为保存数据的最后手段来使用，当负责保存数据的后台子进程不幸出现问题时使用。

二、AOF（Append Only File）

AOF：Redis 默认不开启。它的出现是为了弥补 RDB 的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

1.原理

Redis 以日志的形式来记录每个写操作，将 Redis 执行过的所有写指令记录下来(读操作不记录)。

只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.RDB保存的文件

AOF保存的文件是 appendonly.aof 文件 ,位置保存在 Redis 的启动目录。如果开启了 AOF，Redis 每次记录写操作都会往 appendonly.aof 文件追加新的日志内容。

3.配置RDB 持久化策略

在 redis.conf 的快照配置中，配置 AOF 保存的策略：
- appendonly：配置是否开启AOF，yes表示开启，no表示关闭。默认是no。
- appendfilename：AOF保存文件名。
- appendfsync：AOF异步持久化策略：
  - always：同步持久化，每次发生数据变化会立刻写入到磁盘中，性能较差但数据完整性比较好（慢，安全）；
  - everysec：出厂默认推荐，每秒异步记录一次（默认值）；
  - no：不即时同步，由操作系统决定何时同步；
- no-appendfsync-on-rewrite：重写时是否可以运用appendsync，默认no，可以保证数据的安全性。
- auto-aof-rewrite-percentage：设置重写的基准百分比。
- auto-aof-rewrite-min-size：设置重写的基准值。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

如果因为某些原因导致 appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令 redis-check-aof --fix appendonly.aof 进行修复，会把出现异常的部分往后所有写操作日志去掉。

4.AOF 的重写

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

AOF文件持续增长而过大时，会 fork 出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的 Set 语句。重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。

Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。当然，也可以在配置文件中进行配置。