Redis 中 RDB 和 AOF 持久化有啥区别？看这儿，你就懂了，java并发编程实战读后感

GitHub地址：https://github.com/abel-max/Java-Study-Note/tree/master

概念

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

Redis 是内存数据库，数据存储在内存中，一旦服务器进程退出，数据就丢失了，所以 Redis 需要想办法将存储在内存中的数据持久化到磁盘。

Redis 提供了两种持久化功能：

1. RDB (Redis Database)：生成 RDB 文件，保存的是 key-value 的形式。

2. AOF (Append Only File)：保存 Redis 执行过程中的写命令。

生成

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

RDB 的生成

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

SAVEBGSAVE

如果两个 key 值的修改具有事务性，需要手动加事务，不然备份时可能会导致两个值不一致。

除了主动执行命令，我们还可以通过 save 选项设置多个保存条件，只要任意一个条件满足，服务器就会执行 BGSAVE 命令：

save 900 1save 300 10save 60 10000

那么只要满足以下三个条件中的任意一个， BGSAVE 命令就会被执行：

1. 服务器在900秒之内，对数据库进行了至少1次修改。

2. 服务器在300秒之内，对数据库进行了至少10次修改。

3. 服务器在60秒之内，对数据库进行了至少10000次修改。

AOF 的生成

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

只要打开 AOF 持久化功能，服务器在执行完一个写命令后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

现代操作系统中，用户在写文件时，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区被填满，或者超过了指定时限之后，才真正将缓冲区中的数据写入磁盘。这就有可能导致缓冲区内的数据还未写入磁盘，计算机发生停机，导致数据丢失。

appendfsync 选项的值可以决定 AOF 持久化功能的效率和安全性：

alwayseverysecno

AOF 的重写

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

因为 AOF 保存的是写命令，随着服务器的运行，同一个键值被操作的次数越多，单个键值就会产生多条写命令，AOF 文件就会越大，还原的时间就会越久。

为了解决 AOF 体积膨胀的问题，Redis 提供了 AOF 文件重写（rewrite）功能。

AOF 重写并不是对旧的 AOF 文件进行压缩。Redis 会从数据库中读出数据，生成对应的写命令，并写入新的 AOF 文件中，当新的 AOF 文件重写了所有数据的写命令，就可以替换掉旧 AOF 文件。

AOF 重写可以在后台进行，在重写过程中新产生的数据，会写入 AOF 重写缓冲区中，当重写结束再把缓冲区的写命令追加到新的 AOF 文件中即可。