redis持久化文件+持久化机制（rdb和aof）+aof重写机制+redis4.0后混合持久化机制

本文将学习redis持久化文件和持久化机制（RDB、AOF）

一.redis持久化文件

redis持久化文件默认为dump.rdb和appendonly.aof，默认都在./目录下，这两个在redis.conf配置文件中有定义：

# rdb持久化文件名
dbfilename dump.rdb

# 工作目录。持久化文件会生成到这个目录下，可以修改为固定地址
dir ./

#是否开启aof，默认不开启

appendonly no

#aof持久化文件名，默认不开启aof也不会生成aof文件

appendfilename "appendonly.aof"

那么持久化文件有什么作用呢，什么时候生成的呢？这个文件的作用顾名思义就是进行redis数据持久化的，简单来说就是redis将数据从内存保存到磁盘中，下次服务重新启动时会根据持久化文件将上一次服务在线时的数据从这个持久化文件中重新加载恢复。

二.redis持久化机制之RDB

（1）什么是RDB？

redis的rdb持久化机制原理是redis会单独创建（folk）一个和主进程一模一样的子进程来进行持久化操作，这个子进程的所有数据局（变量，环境变量，程序计数器等）都跟原进程一样。当触发rdb操作时，redis会先将要持久化的数据写到一个临时文件中，等持久化结束之后再将这个临时文件替换上一次持久化好的文件，整个过程都由子进程完成，主进程不再进行任何io操作，从而保证了极高的性能。

（2）什么时候folk子进程，持久化时产生临时文件对上一次持久化好的文件进行替换，主进程在持久化时不再参与io操作，怎么验证？

我们知道，redis是一个单线程的高性能缓存key-value数据库。这里说的单线程实际上是指在接收网络请求时是单线程处理的，如下图三个客户端redis-cli同时发送命令过来时redis会将这多个同时过来的命令进行排队，然后按照排队顺序一个个往下执行，而将排队的命令取出来进行处理或持久化的过程中就不一定是单线程完成了，因此单线程的概念是对客户端网络请求处理时而言的，整个redis的工作过程并非完全是单线程完成的，同时也就没有并发问题。

上面简单介绍了RDB机制的原理过程，我们知道当触发rdb操作时，redis会先将要持久化的数据写到一个临时文件中，等持久化结束之后再将这个临时文件替换上一次持久化好的文件，整个过程都由子进程完成，主进程不再进行任何io操作，从而保证了极高的性能。那么我们要怎么验证这几个问题呢？下面通过预先在dump.rdb文件中存放百万条数据重新恢复到redis中，然后进行触发rdb操作通过查看触发前、中、后这几个时间差内产生的文件和现象来验证这个结论。

首先，通过java代码往redis中写入500万条记录：

<!-- 在pom依赖中添加jedis依赖 -->
<dependencies>
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>2.9.0</version>
    </dependency>
</dependencies>

package com.redis.test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
import java.util.stream.IntStream;
/**
 * 新增500万条redis记录
 */
public class RedisTest {
    pub