Redis缓存持久化

川长思鸟来 2022-09-12 14:44 159阅读 0赞

## 缓存持久化 ##

### RDB ###

RDB持久化是把当前进程数据生成快照保存到硬盘，

命令为

*  `save` 阻塞执行，已废弃
 *  `bgsave` 创建子进程执行

bgsave执行结果

33375:M 24 Sep 16:39:02.580 * Background saving started by pid 34280
    34280:C 24 Sep 16:39:02.592 * DB saved on disk
    34280:C 24 Sep 16:39:02.593 * RDB: 6 MB of memory used by copy-on-write
    33375:M 24 Sep 16:39:02.599 * Background saving terminated with success

save执行结果

33375:M 24 Sep 16:39:02.599 * Background saving terminated with success
    33375:M 24 Sep 16:41:27.320 * DB saved on disk

触发机制：

*  手动触发
 *  自动触发
    
     *  1） 使用save相关配置， 如“save m n”。 表示m秒内数据集存在n次修改时， 自动触发bgsave。
     *  2） 如果从节点执行全量复制操作， 主节点自动执行bgsave生成RDB文件并发送给从节点。
     *  3） 执行debug reload命令重新加载Redis时， 也会自动触发save操作。
     *  4） 默认情况下执行shutdown命令时， 如果没有开启AOF持久化功能则自动执行bgsave。

bgsave运行流程

![1632473860585-20210924165740.png][]

文件压缩

Redis默认采用LZF算法对生成的RDB文件做压缩处理， 压缩后的文件远远小于内存大小， 默认开启， 可以通过参数config setrdbcompression\{yes|no\}动态修改。虽然压缩RDB会消耗CPU， 但可大幅降低文件的体积， 方便保存到硬盘或通过网络发送给从节点， 因此线上建议开启。

RDB优缺点：

<table> 
 <thead> 
  <tr> 
   <th align="left">优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">文件小，适于全量备份，便于传输和恢复<br>Redis加载恢复速度快</td> 
   <td>bgsave创建子进程操作较重，不能实时/秒级持久化，频繁执行成本过高<br>RDB二进制文件新老版本可能会不兼容</td> 
  </tr> 
 </tbody> 
</table>

### AOF ###

记录每次写命令到AOF文件中，恢复时重新执行AOF文件中的命令

<table> 
 <thead> 
  <tr> 
   <th>策略</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>always</td> 
   <td>命令写入aof_buf后调用fsync操作同步到AOF文件，每次写入都会执行，不建议</td> 
  </tr> 
  <tr> 
   <td>everysec</td> 
   <td>命令写入aof_buf后调用系统write操作，write完成后线程返回，fsync同步文件操作由专门线程每秒调用一次。是默认的也是建议的同步策略，兼顾性能和数据安全。理论上宕机只丢1秒数据。</td> 
  </tr> 
  <tr> 
   <td>no</td> 
   <td>命令写入aof_buf后调用write操作，由操作系统负责控制写入AOF，同步周期最长30秒，性能会提升，但安全无法保证。</td> 
  </tr> 
 </tbody> 
</table>

**系统调用write和fsync说明：**

*  write操作会触发延迟写（delayed write） 机制。 Linux在内核提供页缓冲区用来提高硬盘IO性能。 write操作在写入系统缓冲区后直接返回。 同步硬盘操作依赖于系统调度机制， 例如： 缓冲区页空间写满或达到特定时间周期。 同步文件之前， 如果此时系统故障宕机， 缓冲区内数据将丢失。
 *  fsync针对单个文件操作（比如AOF文件） ， 做强制硬盘同步， fsync将阻塞直到写入硬盘完成后返回， 保证了数据持久化。

**重写机制**

为避免AOF文件越写越大，Redis引入AOF重写机制压缩文件体积。 AOF文件重写是把Redis进程内的数据转  
化为写命令同步到新AOF文件的过程。

文件变小原理：

1.  进程内超时数据不再写入文件
2.  删除无效命令如:del等，只使用进程内数据直接生成，保留最终写入命令
3.  集合多次操作命令合并，以64个元素为界拆分为多条

触发：

*  手动： 调用bgrewriteaof命令。
 *  自动：根据参数确定自动触发时机。
    
     *  auto-aof-rewrite-min-size: AOF重写最小体积
     *  ·auto-aof-rewrite-percentage： 代表当前AOF文件空间（ aof\_current\_size） 和上一次重写后AOF文件空间（ aof\_base\_size） 的比  
        值。

自动触发时机=aof\_current\_size>auto-aof-rewrite-min-size&&（ aof\_current\_size-aof\_base\_size）/aof\_base\_size>=auto-aof-rewrite-percentage  
其中aof\_current\_size和aof\_base\_size可以在info Persistence统计信息中查看。

127.0.0.1:6380> info Persistence
    # Persistence
    loading:0
    rdb_changes_since_last_save:2
    rdb_bgsave_in_progress:0
    rdb_last_save_time:1632476935
    rdb_last_bgsave_status:ok
    rdb_last_bgsave_time_sec:0
    rdb_current_bgsave_time_sec:-1
    aof_enabled:1
    aof_rewrite_in_progress:0
    aof_rewrite_scheduled:0
    aof_last_rewrite_time_sec:0
    aof_current_rewrite_time_sec:-1
    aof_last_bgrewrite_status:ok
    aof_last_write_status:ok
    aof_current_size:199
    aof_base_size:199
    aof_pending_rewrite:0
    aof_buffer_length:0
    aof_rewrite_buffer_length:0
    aof_pending_bio_fsync:0
    aof_delayed_fsync:0

aof重写流程

![1632479984947-20210924183944.png][]

### 持久化文件加载流程 ###

![1632480095856-20210924184135.png][]

Redis单线程架构导致无法充分利用CPU多核特性， 通常的做法是在一台机器上部署多个Redis实例。 当多个实例开启AOF重写后， 彼此之间会产生对CPU和IO的竞争。 如果同一时刻运行多个子进程， 对当前系统影响将非常明显， 因此单机下部署多实例时需要采用一种措施， 把子进程工作进行隔离。通过`info Persistence`命令可以获取监控子进程运行状况的度量指标。基于以下这些指标，可以通过外部程序轮询控制AOF重写操作的串行执行。

![1632623914351-20210926103833.png][]

[1632473860585-20210924165740.png]: /images/20220828/3b0b4951eff84df59c4cf4d99c6ace9b.png
[1632479984947-20210924183944.png]: /images/20220828/46786e7485ed4f3096714f6f0bcbd758.png
[1632480095856-20210924184135.png]: /images/20220828/5b68bb26560b4b6d98effb9bddb96545.png
[1632623914351-20210926103833.png]: /images/20220828/c7fd1398cd5c45f39f09b39261e37180.png