noSql
redis

redis-数据持久化配置

redis的数据持久化功能默认是没有开启的，当我们kill掉redis-server进程并重启后，此前所有的缓存数据都会丢失，所以为了防止redis服务器宕机而造成数据丢失，我们应该打开redis的数据持久化功能。

redis持久化方式有两种：RDB 和 AOF，本文将围绕这两种持久化方式展开。

1、持久化原理

  • RDB的原理是生成当前数据集的快照文件dump.rdb，当服务器宕机重启后，服务器会根据该备份文件恢复数据，备份的是数据。
  • AOF的原理是维护一个数据写入日志（aof文件），在服务器执行写入命令的时候，在aof文件尾部添加命令。服务器宕机重启后，自动执行aof文件中的数据写入命令恢复数据。

2、运行过程

2.1 RDB方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

  1. Redis 调用 fork() ，同时拥有父进程和子进程。
  2. 子进程将数据集写入到一个临时 RDB 文件中。
  3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

2.2 AOF方式

每当 Redis 执行一个改变数据集的命令时（比如 SET、INCR）， 这个命令就会被追加到 AOF 文件的末尾， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

AOF重写

举个例子， 如果你对一个计数器调用了 100 次INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录。

然而在实际上， 只使用一条 SET 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。

执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。

重写过程

AOF 重写和 RDB 创建快照一样，都巧妙地利用了copy-on-write机制。

  1. Redis 执行 fork() ，现在同时拥有父进程和子进程。
  2. 子进程开始将新 AOF 文件的内容写入到临时文件。
  3. 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
  4. 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  5. 现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

3、配置方式

4.1 RDB配置

手动触发

RDB通过手动执行命令SAVE或者BGSAVE生成快照文件，SAVE会阻塞服务器进程直到成功生成备份，不推荐使用；使用BGSAVE，服务器进程会fork一个子进程，异步执行备份，此过程服务器只有在fork()的时候阻塞。

自动触发(配置文件)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 停用rdb
#save ""
save 900 1 #表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10 #表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000 #表示60 秒内如果至少有 10000 个 key 的值变化，则保存

#当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据，默认yes
stop-writes-on-bgsave-error yes

#对于存储到磁盘中的快照，可以设置是否采用LZF进行压缩存储，默认yes
rdbcompression yes

#在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验
#但是这样做会增加大约10%的性能消耗，默认yes
rdbchecksum yes

#设置快照的文件名，默认是 dump.rdb
dbfilename dump.rdb

#设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名
dir /var/redis/6379

3.2 AOF配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 开启aof
appendonly yes

# aof文件名称
appendfilename "appendonly.aof"

# 三种持久化策略
# appendfsync always  # 每次修改数据集都会追加一次
appendfsync everysec  # 每1秒追加一次 
# appendfsync no  # 交给系统控制，linux 系统是30秒

# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no

# 当aof文件增长量达到100%，自动重写（设为0则永不重写）
auto-aof-rewrite-percentage 100
# 当aof文件小于这个值，不会自动重写
auto-aof-rewrite-min-size 64mb

# 
aof-load-truncated yes

# 
aof-use-rdb-preamble no

4、优劣势对比

RDB AOF
备份策略灵活多样可配置 只有三种持久化策略
rdb文件内容紧凑，适合灾难恢复 -
备份过程不影响redis性能 持久化策略决定是否影响redis性能
大数据集恢复速度快 大数据量恢复速度较慢
可靠性地，丢失数据概率高 持久化可靠性高，丢失数据概率低
rdb文件不可读 aof文件可读性高，易于分析
每次生成快照都需要操作整个数据集 aof文件只需要进行追加操作

总结来说：

RDB方式备份时费劲，恢复时很给力，持久化可靠性低；AOF方式备份简单，恢复时稍费力，持久化可靠性高。具体使用哪种方式，需要根据具体业务场景进行选择。