Redis持久化方式-AOF与RDB

最新推荐文章于 2023-05-28 14:36:47 发布

HS_Henry

最新推荐文章于 2023-05-28 14:36:47 发布

阅读量218

点赞数

本文链接：https://blog.csdn.net/chl87783255/article/details/99671374

版权

陈海龙的格物之路-Redis篇专栏收录该内容

19 篇文章 2 订阅

订阅专栏

AOF rewrite和RDB fork过程会同时执行吗？

目标

讲述redis两种持久化方式，即aof和rdb，内容包括各自流程与优缺点、场景选型、备份方式。

概述

Redis提供AOF和RDB两种持久化方式。

AOF是把操作指令追加到log文件，也会按照规则整理文件。AOF文件是相对最完整的数据，所以每次server启动都会读取AOF日志文件，已重建数据集合。

RDB是依据周期频率对数据集合制作快照。

可以同时关闭两种方式，仅提供运行时数据集合，也可以配合使用。

AOF rewrite和RDB均由子进程执行，一般不会影响redis处理client请求。

AOF

概述

对指令以log形式持久化，可较好减少数据丢失。当log文件很大时，会自动在后台进行rewrite过程，以便用最小操作集合来表示当前数据集合，即缩小log文件大小，但不影响redis请求。

配置（更多配置请见redis.conf）

appendonly yes

rewrite

由图可见，rewrite是由子进程执行，不会阻塞redis server处理client请求。

控制rewrite自动执行的条件（更多配置请见redis.conf）

// 当前aof log 增加的大小  到达  最近rewrite后aof log大小  的百分比时，触发rewrite
auto-aof-rewrite-percentage 100
// 到达百分比 且 当前log文件大小必须大于该值
auto-aof-rewrite-min-size 64mb

优点

AOF提供3种文件同步fsync方式

不进行fsync
每秒fsync
每次查询同步

（更多配置请见redis.conf）

# appendfsync always
appendfsync everysec
# appendfsync no

每秒同步是默认方式，而且表现的很好，灾难时只会丢失最近一秒的数据。由background线程来执行fsync，只有当fsync没有执行时，main线程才可以进行写。

AOF仅支持append追加log，所以数据不会乱。

当log太大时，redis可以自动的进行AOF rewrite。rewrite过程可以安全的完成，因为redis会在旧的AOFlog中追加，一个新的AOFlog是能构代表当前数据集合的最少操作指令集合，当新log完成后redis就会向新log中追加。

AOF log包含易懂的指令操作，可以导出后修改，再使用该log启动redis，达到修改数据的目的。例如由于错误操作导致了问题，可以执行FLUSHALL指令，然后停止redis，删除log中后边的操作，然后启动redis。

缺点

表示同样数据集合，AOF文件占空间大。当write请求很多时，RDB表现的更加稳定。

RDB

概述

将数据集合以二进制的形式存储到名为dump.rdb的文件中，执行频率使用save进行配置，可以配置为每N秒或每M次更新操作，也可通过SAVE和BGSAVE指令形式触发。

配置（更多配置请见redis.conf）

save 900 1
save 300 10
// 每60秒且1000次更新
save 60 10000

流程

由图可见，rdb过程也是由子进程执行的，不会阻塞redis server处理client请求。

优点

RDB以单独的压缩文件的形式存储了redis某个时间点的数据集合快照，很适合用来备份和数据版本，例如每小时备份一次。

可将压缩文件存到其他位置，如数据中心或云存储，以便使用RDB文件进行容灾。

RDB可以提升redis的性能，因为parent 进程可以把持久化工作交给child 进程，这样parent 进程就不会进行磁盘IO。

与AOF相比，server使用RDB重建数据时，可以更快的启动。

缺点

不擅长防止数据丢失。虽然持久化规则可以配置的频率更高，但是会产生很多快照文件，而且server非正常停止情况，可能丢失最近几分钟的数据。

RDB需要经常fork()子进程来完成持久化工作，当数据集合很大并且cpu处理能力有限的情况下，可能引起redis停止对client服务，时间可达数毫秒甚至1秒。AOF在rewrite时也需要fork，但是可以调节rewrite的频率而不需要考虑持久性。

场景选型

基于场景需求，从数据持久性和数据丢失角度考虑。

建议AOF和RDB一起使用，因为AOF保证最少数据丢失，RDB保证更好的持久化/版本备份/快速restart，但是restart时默认是使用AOF，因为数据最全。
持久化要求高，版本备份，最少数据丢失，类似database：AOF＋RDB
持久化要求高，版本备份，但不关心数据丢失：RDB
持久化要求低，不需备份，最少数据丢失：AOF
持久化低，不关系数据丢失，类似内存级缓存：两者都不用