redis 的持久化方式

最新推荐文章于 2024-08-27 11:41:43 发布

红丶

最新推荐文章于 2024-08-27 11:41:43 发布

阅读量91

点赞数

分类专栏： redis 文章标签： redis

本文链接：https://blog.csdn.net/weixin_42494845/article/details/110186556

版权

redis 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

问题

Redis的数据都缓存在内存中，如果没有配置持久化， redis 宕机了再重启，内存里的数据就全部都弄丢了啊。于是需要开启redis的持久化功能，将数据写入内存的同时，异步的慢慢的将数据写入磁盘文件里，进行持久化。

当redis 宕机重启，会自动从磁盘上加载之前持久化的一些数据，也许会丢失少许数据，但是至少不会将所有数据都弄丢。

可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

为什么要做持久化？

持久化主要是做灾难恢复、数据恢复，也可以归类到高可用的一个环节中去，比如你 redis 整个挂了，然后 redis 就不可用了，你要做的事情就是让 redis 变得可用，尽快变得可用。

重启 redis，能尽快让它对外提供服务，但是如果没做数据备份，这时候 redis 启动了，因为数据都没有了，也是不可用的。

很可能大量的请求过来，缓存全部无法命中，出现缓存雪崩问题。所有请就会去 mysql 数据库这种数据源头中去找，一下子 mysql 承接高并发，导致mysql服务崩溃。

如果把 redis 持久化做好，备份和恢复方案做到企业级的程度，那么即使你的 redis 故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务。

redis 的持久化有哪几种方式？

redis 持久化有两种方式

RDB：RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

RDB持久化配置
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率。

 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
- save 900 1             
#在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
- save 300 10            
#在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
- save 60 10000

AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。

AOF持久化配置
在Redis的配置文件中存在三种同步方式，它们分别是：

 #每次有数据修改发生时都会写入AOF文件。
appendfsync always    
#每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync everysec  
#从不同步。高效但是数据不会被持久化。
appendfsync no

通过 RDB 或 AOF，都可以将 redis 内存中的数据给持久化到磁盘上面来。
如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。

不同的持久化机制都有什么优缺点？

RDB 优缺点

RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。

相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。

如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

AOF 优缺点

AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。

AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。

AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。