数据库面试题：Redis数据存储在哪里？如何保证数据持久化？_redis数据存储在哪儿?

一. Redis数据存储位置

• redis是一个内存数据库, 因此数据基本上都存在于内存当中
• 但是Redis会定时以追加或者快照的方式刷新到硬盘中.
• 由于redis是一个内存数据库, 所以读取写入的速度是非常快的, 所以经常被用来做数据, 页面等的缓存。

二. Redis如何保证数据持久性

• Redis保证数据持久性的方式有两种：
• RDB持久化（）：RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
• AOF持久化（）：一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。然后在服务重启以后，会执行这些命令来恢复数据。

2.1 RDB持久化

• RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

RDB的优势：

• RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
• 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB的劣势：

• RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。
• 当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

RDB的触发机制：

• RDB持久化的触发机制有三种：save、bgsave、自动化

2.1 save

• 该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。具体流程如下：
• 执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

2.2 bgsave

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

2.3 自动触发

• 在配置中集中配置 save m n 的方式，表示 m秒内数据集存在n次修改时，系统自动触发bgsave 操作。

2.2 AOF持久化

• 全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
• 然后在服务重启以后，会执行这些命令来恢复数据。

AOF文件重写：

• AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。。
• AOF 文件重写就是把 Redis 进程内的数据转化为写命令，然后同步到新的 AOF 文件中。在重写的过程中，Redis 服务器会创建一个新的 AOF 文件来替代现有的 AOF 文件，新、旧两个 AOF 文件所保存的数据库状态相同，但是新的 AOF 文件不会包含冗余命令。

AOF触发机制：

• appendfsync always：每次收到写命令就立即强制写入磁盘
• appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
• appendfsync no：完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。