Redis的两种持久化方式

1.两种方式：

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

    2.AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

2.二者的优点缺点

    1.RDB优点：

        1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份是非常完美的

        2.对于灾难恢复而言，RDB是非常不错的选择。

        3.性能最大化。对于Redis的服务进程而言，在开始持久化时，他唯一需要做的只是fork出子进程，之后再由子进程完成这项持久化的工作，这样就可以极大的避免服务进程进行IO操作

        4.相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

    2.RDB缺点：

        1.如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

        2.由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务。

    3.AOF优点：

        1.该机制可以带来更高的数据安全性，即数据持久性。

        2.由于该机制对日志文件的写入操作采用的是append模式，一次在写入过程中出现宕机现象，也不会破坏日志文件中已经存在的内容。

        3.如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些命令被执行。

        4.AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

    4.AOF缺点：

        1.对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度要比AOF的恢复速度要快。

        2.根据同步策略的不同，AOF在运行效率上往往会慢于RDB的。

3.常用配置

    1.RDB持久化配置

    save 900 1 #在900秒之后，如果至少有1个key发生变化，则dump内存快照

    save 300 10 #在300秒之后，如果至少有10个key发生变化，则dump内存快照

    save 60 10000 #在60秒之后，如果至少有10000个key发生变化，则dump内存快照

    2.AOP持久化配置

    appendfsync always #每次有数据修改时都会写入AOF文件

    appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略

    appendfsync no #从不同步，高效但是数据不会被持久化

4.执行流程：

    1.RDB执行流程

        1.Redis使用fork函数复制一份当前的父进程作为子进程

        2.父进程继续处理用户的请求，子进程开始把内存中的数据持久化到磁盘上

        3.当子进程把内存中数据写入到临时文件完成之后，会把该临时文件替换掉旧的RDB文件

    2.AOF执行流程

        1.Redis执行fork()，现在同时拥有父进程和子进程。

        2.子进程开始将新AOF文件的内容写入到临时文件

        3.对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有AOF文件的末尾；这样即使在重写的中途发生停机，现有的AOF文件也还是安全的。

        4.当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新AOF文件的末尾。

        5.现在Redis原子地用新文件替换旧文件，之后所有的命令都会直接追加到新AOF文件的末尾。

转载于:https://my.oschina.net/LeBronJames/blog/1927175