04-Redis 数据持久化实践，这些数据库索引的高频面试题你会吗

最新推荐文章于 2024-11-01 12:20:35 发布

2401_84023579

最新推荐文章于 2024-11-01 12:20:35 发布

阅读量630

点赞数 22

分类专栏： 2024年程序员学习文章标签：数据库 redis java

本文链接：https://blog.csdn.net/2401_84023579/article/details/137210696

版权

2024年程序员学习专栏收录该内容

238 篇文章 0 订阅

订阅专栏

首先,打开第一个客户端,先清除redis内存和磁盘对应的数据

[root@centos7964 data]# docker exec -it redis01 redis-cli

127.0.0.1:6379> flushall

127.0.0.1:6379> exit

[root@centos7964 data]# ls

dump.rdb

[root@centos7964 data]# rm –f dump.rdb

[root@centos7964 data]# ls

然后,打开并登录第二个客户端,并向redis存储一些数据,例如

[root@centos7964 ~]# docker exec -it redis01 redis-cli

127.0.0.1:6379> set one mybatis

127.0.0.1:6379> set two spring

127.0.0.1:6379> keys *

“one”
“two”

接下来,再次回到第一个客户端,杀掉redis进程,例如

[root@centos7964 data]# ps -ef | grep redis

polkitd 6995 6974 0 14:44 ? 00:00:00 redis-server *:6379

root 7064 6974 0 14:44 pts/0 00:00:00 redis-cli

root 7111 6467 0 14:47 pts/1 00:00:00 docker exec -it redis01 redis-cli

root 7130 6974 0 14:47 pts/1 00:00:00 redis-cli

root 7278 7180 0 14:51 pts/0 00:00:00 grep --color=auto redis

[root@centos7964 data]# kill -9 6995

[root@centos7964 data]# docker start redis01

最后,打开第一个客户端,登录redis,检查key是否还存在.

[root@centos7964 ~]# docker exec -it redis01 redis-cli

127.0.0.1:6379> keys *

(empty array)

127.0.0.1:6379>

[root@centos7964 ~]#

试验三

手动调用save(同步保存)或者bgsave(异步保存)执行rdb快照生成.然后杀掉redis进程,再重启检测是否还有刚刚保存的数据.

127.0.0.1:6379> set id 100

127.0.0.1:6379> set name jack

127.0.0.1:6379> save #阻塞式持久化

127.0.0.1:6379> set address beijing

127.0.0.1:6379> bgsave #异步方式持久化

Background saving started

小节面试分析

Redis中的save和bgsave有什么不同？

Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制有哪些优点？

第一：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据.

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

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

RDB持久化机制有哪些缺点？

假如redis故障时，要尽可能少的丢失数据，那么RDB方式不太好，它都是每隔5分钟或更长时间做一次快照，这个时候一旦redis进程宕机，那么会丢失最近几分钟的数据。

Aof方式数据持久化

====================================================================

概述

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。

AOF方式配置

是否开启AOF，默认关闭

appendonly yes

指定 AOF 文件名

appendfilename appendonly.aof

Redis支持三种刷写模式：

appendfsync always #每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。

appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。

appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。

#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。

#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes

no-appendfsync-on-rewrite yes

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-percentage 100

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

auto-aof-rewrite-min-size 64mb

AOF方式持久化实践

第一：打开AOF的开关，启用AOF持久化

第二：写入一些数据，观察AOF文件（appendonly.aof）中的日志内容

第三：kill -9杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，就是从AOF文件中恢复回来的，redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来。

小节面试分析

如何理解AOF方式中的rewrite操作？

redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉。也就是说redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，最好导致文件很大。

所以,AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据; 于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中; 覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致.

AOF持久化机制有哪些优点？

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

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

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

第四：AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据.