Redis持久化学习

• redis作为当今最火热的nosql数据库，无论在互联网领域还是在传统金融，电信等领域都是备受推崇！作为一名IT从业者，去理解掌握redis的背后的设计理念对于灵活使用redis还是非常有必要的。
• RDB与AOF可以同时运行，redis在启动时，如果发现开启aof，则会优先加载aof文件。

RDB持久化

• 原理：RDB持久化每次都是全量存储，保存某一个时刻的所有数据快照。保存RDB时，父进程fork出一个子进程，由子进程进行持久化，子进程将父进程当前时刻的数据生成新的rdb文件，替换旧RDB文件。然后通知父进程。
• 父进程fork完子进程后，继续响应客户端请求，但是父进程在创建fork过程中对于客户端是阻塞的。
• RDB持久化原理如下图所示：
  -

触发持久化方式

1. 手动触发：手动触发有save和bgSave两种方式。

   • save：生产环境不建议使用，消耗资源比较严重,属于阻塞模
   • bgSave：触发父进程fork出子进程方式，如上图所示。

2. 自动触发：可以通过设置配置文件设置，进行自动触发持久化
   
   上图表示：
   save 900 1表示在900秒后，如果有1个key发生改变，则触发持久化
   save 300 10 在300秒后，如果有10个key发生改变，则触发持久化
   save 60 10000在60秒后，有10000个key发生改变，则触发持久化

RDB持久化优点

1. 文件比较紧凑，体积较小，适合备份
2. 数据恢复时速度比AOF方式要快
3. 保存文件时，可以通过子进程进行生成RDB文件

RDB缺点

1. RDB不能实时或秒级持久化数据，需要手动触发或者设置成一定条件 才可以。
2. 数据量巨大时，RDB非常消耗资源，性能不高
3. 服务器发生宕机时，容易丢失一定时间内的数据，对于数据要求比较高的业务场景时不适用

AOF持久化

相对于RDB的持久化，redis更建议使用aof方式持久化。先通过一张aof原理图去了解吧！

原理：aof采用文件追加的方式进行文本存储，不同于rdb的二进制存储方式。redisf服务端每次收到client请求的修改，写入命令先存入缓存中(aof_buf),直接操作磁盘性能会受到影响，最终都会将缓存中的命令和数据写入到aof文件中。aof追加文件的方式最大程度上保证了数据持久化，但是aof文件相比rdb文件要大很多。
AOF文件刷盘策略：
1. 在从aof_buf中往磁盘写入文件时，redis提供了三种aof文件刷盘策略默认采用每秒刷盘一次：
- always:每次有新增写入命令，都会调用fsync函数追加到aof文件中，性能最慢，数据最安全。
- no:调用write函数将缓存中的数据写入系统缓冲区即返回。由os每隔30秒将数据追加到aof文件中，性能最高，数据不安全。
- everysec：每秒刷盘一次，默认配置，兼顾了数据安全和性能。redis调用write函数将内存中的数据写入系统缓冲区后，即返回。由os每隔一秒调用fsync()函数将系统缓冲区的数据追加到磁盘中。这种方式，服务器宕机时，一般会丢失1秒左右系统缓冲区的数据。
- 下图就是redis中的aof配置：

AOF文件重写

**目的：**aof持久化是将所有的命令以追加的方式写入aof文件。这就造成了aof文件中存储了大量的无效命令。aof文件重写将aof文件中的无效命令，多余的命令进行合并(多次修改同一个key的值)去掉，使得aof文件存储的是数据的最终状态。这样aof文件会节省一部分磁盘空间。通过下图来了解一下aof重写的原理：

触发方式
重写可以手工调用bgrewriteaof命令或者自动触发该命令。
2. 流程：
- bgrewriteaof命令触发aof重写，父进程收到该触发命令时，会fork出子进程（父进程fork子进程时是阻塞的）。
- 子进程将redis内存中的数据重新写入新的aof文件中，重写过程只会保存数据的最终状态，无用的命令将会被抛弃。
- 父进程fork出子进程后，会继续响应client的请求，同时将新增的修改，写入命令写入aof_rewrite_buf中。即，后续的client请求写，修改命令既要写入原有的aof文件中，同时还追加到aof_rewrite_buf中。
- 子进程生成新的aof文件后通知父进程，父进程会将aof_write_buf中的内容追加到新的aof文件中。同时将新aof文件替换旧的aof文件。
- 子进程生成新的aof文件过程，先将数据写入到OS缓存中，然后根据持久化刷盘策略，调用OS函数fsync写入到aof文件中。

AOF持久化优点

1. 持久化策略多，主要有always,no,fsync。
2. 相对RDB，可以做到实时/秒级持久化，数据丢失最少。即使服务器宕机，也只会丢失极少数部分数据。
3. redis在后台可以自动重写aof文件，同时redis可以继续将现有的修改，写入命令追加到aof文件，aof文件不断的重写，使得aof文件可以一直在压缩存储。
4. aof文件保存了所有了修改，写入命令。

AOF持久化缺点

1. aof文件通常比RDB文件要大很多，因为不仅需要保存数据同时还需要保存修改，写入命令。
2. 海量数据恢复时，aof比RDB要慢。
3. 容易发生redis阻塞。同步线程每秒将aof_buf内容刷新到aof文件中。如果超过2秒，redis主线程将会阻塞。