一. 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秒左右一次，性能最好但是持久化最没有保证，不推荐。