redis数据持久化_RDB_AOF

redis作为内存数据库,一共支持2种数据持久化方案:RDB、AOF。这两种方案把数据存储到磁盘中,既可以同时使用,也可以单独使用,甚至都不使用,具体使用可以配置。
把数据存储到磁盘主要是为了以后重用数据,或者防止系统出现故障而将数据备份到远程位置。

一、RDB

1.1、rdb原理:

rdb的主要原理是在某个时间点,把内存中所有的数据做一份快照,然后把快照中的数据保存在磁盘中。

1.2、rdb默认配置是:

1
2
3
4
5
6
7
8
save 900 1     #900秒时间,至少有一条数据更新,则保存到数据文件中
save 300 10    #300秒时间,至少有10条数据更新,则保存到数据文件中
save 60 10000  #60秒时间,至少有10000条数据更新,则保存到数据文件中
stop-writes-on-bgsave-error yes
rdbcompression yes 指定存储至本地数据库时是否压缩数据,默认是yes,redis采用LZF压缩,如果为了节省CPU时间可以关闭该选项,但会导致数据库文件扁的巨大
rdbchecksum yes 对rdb文件进行校验
dbfilename "dump.rdb"
dir "XXX"

1.3、创建快照的方法

  • 1、客户端发送bgsave的命令;
  • 2、客户端发送save的命令;
  • 3、redis的save配置被满足时;
  • 4、redis关闭服务器时;
  • 5、主从复制操作时候:当redis a连接redis b并且成为b的从,那么b就会执行bgsave操作,然后把数据传送给a进行同步。

1.4、save操作

redis的save命令是阻塞的,当save命令被触发的时候,由于redis单线程单进程全部在处理快照数据,那么这个时候redis是拒绝一切请求的

1.5、bgsave操作

当redis的bgsave命令触发时:会fork一个新进程,在新进程中进行处理快照的操作,主进程依旧可以执行别的请求。

1.5、fork的copy on write

当执行bgsave的时候,fork子进程,子进程会复制一份主进程的内存数据(fork原理),所以新进程才能创建数据快照。那难道内存中数据有10G,当执行bgsave的时候会变成20G吗?答案当然不是的。这是因为使用了fork的copy on write(写时复制)功能。
在Linux程序中,fork()会产生一个和父进程完全相同的子进程,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。

二、AOF

2.1、aof原理

aof持久化是将被执行的写命令,写到aof文件的末尾,以此来记录数据的变化。

2.2、aof默认配置是:

1
2
3
4
appendonly no   #是否开启aof。默认是关闭的
# appendfsync always       # always:表示每次redis写操作都会同步写入磁盘,这样会严重降低redis速度。
appendfsync everysec       # everysec:表示每秒同步一次(折衷,默认值),通过redis的时间事件
# appendfsync no     # no:表示redis不主动同步aof数据。等操作系统进行数据缓存同步到磁盘(快)

2.3、aof重写

由于AOF记录了数据库的所有写命令,所以随着服务器的运行,AOF文件中内容会越来越大。实际上,对于一个键值,由于多次的修改,会产生很多写命令;中间的一些写操作可以直接省去,直接把最终的键值信息记录到AOF文件中即可,从而减小AOF文件大小。

2.4、aof重写原理

其实redis的bgrewriteaof命令跟bgsave命令非常相似。都是创建一个子进程,把当前的数据创建一份快照,由子进程进行保存,然后替代以前的aof文件(并不是追加都文件末尾)。

2.5、AOF重写缓冲区

当bgrewriteaof正在执行的时候,主进程正在执行请求,如果有写命令的时候,会把写命令存入AOF重写缓冲区。当bgrewriteaof执行完后会把AOF重写缓冲区的内存保存到aof文件中。

三、优缺点

3.1、rdb优点

  • 数据紧凑,方便传输
  • 执行bgsave不会占用主进程开销
  • 数据量大的时候,rdb文件更易于恢复。所以主从复制的时候是传输rdb

3.2、rdb缺点

  • 创建快照的时间不频繁,如果redis停止工作(非正常关闭),可能会丢失几分钟的数据。
  • 在数据量很大,CPU性能不够好的时候,fork调用很耗时,可能导致redis在几毫秒阻塞。

3.3、aof优点

  • 持久化的数据更可靠:默认 everysec(每秒同步一次)。所以最多丢失1s的写操作。
  • aof是以在文件末尾追加日志的形式,更加安全。可以使用redis-check-aof工具快速进行修复
  • 日志变大后,使用自动重写机制来减少文件大小。
  • aof日志格式方便理解,纯粹的就是写操作的字符串命令

3.4、aof缺点

  • aof文件要比rdb文件大的多。
  • aof重写,因为文件大,删除几十G的文件可能会导致系统挂起数秒

四、如何选择持久化方式

这个取决与应用场景。redis默认是开始rdb,关闭aof:

  • 比较关心数据,但是可以忍受几分钟数据的丢失,可以使用rdb;
  • 不建议只使用aof:因为rdb文件是恢复数据、复制数据的最好的办法;
  • 如果对数据要求特别高,可以同时使用两种方案;
文章目录
  1. 1. 一、RDB
    1. 1.0.1. 1.1、rdb原理:
    2. 1.0.2. 1.2、rdb默认配置是:
    3. 1.0.3. 1.3、创建快照的方法
    4. 1.0.4. 1.4、save操作
    5. 1.0.5. 1.5、bgsave操作
    6. 1.0.6. 1.5、fork的copy on write
  • 2. 二、AOF
    1. 2.0.1. 2.1、aof原理
    2. 2.0.2. 2.2、aof默认配置是:
    3. 2.0.3. 2.3、aof重写
    4. 2.0.4. 2.4、aof重写原理
    5. 2.0.5. 2.5、AOF重写缓冲区
  • 3. 三、优缺点
    1. 3.0.1. 3.1、rdb优点
    2. 3.0.2. 3.2、rdb缺点
    3. 3.0.3. 3.3、aof优点
    4. 3.0.4. 3.4、aof缺点
  • 4. 四、如何选择持久化方式
  • ,