Redis系列03 -持久化介绍（RDB & AOF）

前言

Redis体系学习整理，点我点我
解决问题：redis数据在内存中，机器宕机了断电了，数据丢失怎么办？

Redis作为Nosql中一员，因其完全基于内存，支持多样的数据结构，单线程，使用多路复用I/O等特点，逐渐成为了各企业技术选型中缓存模块的首选。
因为数据在内存中，带来了高性能的同时，也带来数据易丢失的特点。万一机器故障宕机，内存中的数据将会丢失，造成难以预估状态和损失。
所以数据的备份与持久化，就非常有必要了。
所以今天我们来谈谈，Redis最基本的持久化方案。

持久化数据的常用方案

各系统虽然不同，但是持久化思路是类似的。
最常用的有两种方式：**复制和日志。**下面分别介绍一下。

复制（snapshot快照）

将存储介质中的数据，平移到另一块存储介质中。如果存储的区域比较几种，是非常非常高效的。 包括大家数据HashMap的Rehash，也会数据搬迁平移的过程。

日志（操作日志）

把每条操作，一五一十的记录下来。一个大家比较熟悉的场景，就是DB中的redolog。 他就是记录了SQL运行的记录。在恢复时进行批量操作。

RDB

回归到Redis的持久化方式
RDB：redis中的”复制“的模式称为RDB， 记录下内存中二进制数据的快照。

启动方式

人工启动

• 指令：sava
  * 触发持久化，存储到配置的路径dump.rdb文件中。
  * 会阻塞redis线程，线上用肯定崩。
• 指令：bgsave
  * 通过操作系统fork一个进程，来异步进行save的操作

配置启动

如save 60 10000(60秒或者10000次操作)
具体的配置如下：

特殊启动

* 主从复制时
* 关机shutown时
* 重启reload时

优缺点

优点

• 紧凑压缩的二进制的内存数据，存取高效
• 存储单时间节点上的快照，非常适合全量复制的场景
• 数据恢复明显快于AOF

缺点

1. 无法实时持久化，
2. 消耗资源
3. 存在一定的RDB文件的兼容问题。

AOF

AOF：redis中的”日志“的模式被称为AOF（append only file），将每条修改内存的指令将会记录下来。
配置方式在redis.conf文件中有详细说明，有兴趣深入了解的可以进文件读一读。

开启方式

appendonly yes
appendsync aways
对应的三种策略：

• always（每次都存）：数据0误差，性能低下，会成为瓶颈
• everysec（每秒1次）：
• no （系统配置）

AOF的重写机制

简介：

当指令数量特别多的时候，AOF文件会变的巨大。但是并不是所有AOF指令都是有效的，比如如下三条AOF记录
1：set name1 zhang3
2：set name1 zhang4
3：set name1 zhang5 其实只有这条是内存中的最终状态。
重写后就是把1和2干掉。这样指令就少了非常多。

启动命令：

bgrewriteaof，讲操作指令存储到 ”复制挤压缓冲区“中。

后记

在工作中因为使用集群，而集群的同步，读写分离等特点，让他天生具备了数据备份的特点。所以我们公司的RDB都是默认关闭的。
但是这些知识在集群的主从复制中，会有非常多的使用。或者说主从复制就是依赖RDB和AOF来完成的。学习这个部分后，我们才能更好的理解集群和主从复制。