Redis持久化

一 持久化的作用

1.1 什么是持久化

redis的所有数据保存在内存中，对数据的更新将异步的保存到硬盘上。

1.2 持久化的实现方式

快照：某时某刻数据的一个完成备份，
	-mysql的Dump
    -redis的RDB
写日志：任何操作记录日志，要恢复数据，只要把日志重新走一遍即可
	-mysql的 Binlog
    -Redis的 AOF

二 RDB

2.1 什么是RDB

RDB 是 Redis DataBase 的缩写，即内存块照。因为Redis的数据时存在内存中的，当服务器宕机时，Redis中存储的数据就会丢失。这个时候就需要内存快照来恢复Redis中的数据了。快照就是在某一时刻，将Redis中的所有数据，以文件的形式存储起来。这就类似于照片，当你给朋友拍照时，一张照片就能把朋友一瞬间的形象完全记下来。

Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，这就类似于给 100 个人拍合影，把每一个人都拍进照片里。这样做的好处是，一次性记录了所有数据，一个都不少。

这样就会产生一个问题，当Redis中的数据越大时，快照文件写入磁盘的时间也就越长。那么Redis在写入磁盘的时候会阻塞主线程吗？这就关系到是否会影响Redis的性能了。

Redis提供了两个命令来生产全量的RDB文件，一个是 save ,另一个是 bgsave。

save：在主线程中执行，会导致阻塞；

bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

不用想也知道，我们应该使用哪种方式来生成RDB文件了。

2.2 触发机制-主要三种方式

'''
save(同步)
1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件
2 会造成redis的阻塞（数据量非常大的时候）
3 文件策略：如果老的RDB存在，会替换老的
4 复杂度 o(n)
'''

'''
bgsave(异步，Backgroud saving started)

1 客户端执行bgsave命令----》redis服务端----》异步创建RDB二进制文件（fork函数生成一个子进程（fork会阻塞reids），执行createRDB，执行成功，返回给reids消息）
2 此时访问redis，会正常响应客户端
3 文件策略：跟save相同，如果老的RDB存在，会替换老的
4 复杂度 o(n)
'''

'''
自动（通过配置）
配置   seconds   changes
save   900        1
save   300        10
save   60         10000
如果60s中改变了1w条数据，自动生成rdb
如果300s中改变了10条数据，自动生成rdb
如果900s中改变了1条数据，自动生成rdb

以上三条符合任意一条，就自动生成rdb，内部使用bgsave
'''

#配置：
save 900 1 #配置一条
save 300 10 #配置一条
save 60 10000 #配置一条
dbfilename dump.rdb  #rdb文件的名字，默认为dump.rdb
dir ./ #rdb文件存在当前目录

stop-writes-on-bgsave-error yes #如果bgsave出现错误，是否停止写入，默认为yes
rdbcompression yes #采用压缩格式
rdbchecksum yes #是否对rdb文件进行校验和检验

#最佳配置
save 900 1 
save 300 10 
save 60 10000 
dbfilename dump-${port}.rdb  #以端口号作为文件名，可能一台机器上很多reids，不会乱
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes #出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验

2.3 触发机制-不容忽略的方式

1 全量复制 #没有执行save和bgsave没有添加rdb策略，还会生成rdb文件，如果开启主从复制，主会自动生成rdb
2 debug reload #debug级别的重启，不会将内存中的数据清空
3 shutdown save#关闭会触发rdb的生成

三 AOF(Append Only File)

3.1 RDB问题

耗时，耗性能。

不可控，可能会丢失数据

3.2 AOF介绍

AOF (Append Only File) 持久化默认是关闭的，通过将 redis.conf 中将 appendonly no，修改为 appendonly yes 来开启AOF 持久化功能，如果服务器开始了 AOF 持久化功能，服务器会优先使用 AOF 文件来还原数据库状态。只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。如图：

3.3 AOF的三种策略

日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上

always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件

everysec（默认值）：redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件

no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件

3.4 AOF 重写

因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 服务器、甚至整个宿主计算机造成影响，并且 AOF 文件的体积越大，使用 AOF 文件来进行数据还原所需的时间就越长。

本质就是把过期的，无用的，重复的，可以优化的命令，来优化，这样可以减少磁盘占用量，加速恢复速度。

redis> RPUSH list "A" "B"          // ["A", "B"]
(integer) 2
redis> RPUSH list "C"              // ["A", "B", "C"]
(integer) 3
redis> RPUSH list "D" "E"          // ["A", "B", "C", "D", "E"]
(integer) 5
redis> LPOP list                   // ["B", "C", "D", "E"]
"A"
redis> LPOP list                   // ["C", "D", "E"]
"B"
redis> RPUSH list "F" "G"          // ["C", "D", "E", "F", "G"]
(integer) 5

那么只是为了记录这个 list 键的状态，AOF 文件就需要保存六条命令。

对于实际的应用来说，写命令执行的次数和频率会比上面的简单示例要高得多，所以造成的问题也严重得多。

为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写（rewirte）功能。通过该功能，Redis 服务器可以创建一个新的 AOF 文件，新旧两个 AOF 文件所保存的数据库状态相同，但新 AOF 文件不会包含任何浪费空间的冗余命令，所以新 AOF 文件的体积通常会比旧 AOF 文件的体积小很多。

服务器为了保存 list 键的状态，必须在 AOF 文件中写入六条命令。

如果服务器想要尽量少的命令记录 list 键的状态，那么最简单高效的办法不是去读取和分
析现有 AOF 文件的内容，而是直接从数据库中读取键 list 的值，然后用一条 RPUSH list 
"C" "D" "E" "F" "G" 命令来代替保存在 AOF 文件中的六条命令，这样就可以保存 list 键所
需的命令从六条减少为一条了。

AOF重写配置：

auto-aof-rewrite-min-size     # AOF文件重写需要尺寸
auto-aof-rewrite-percentage   # AOF文件增长率

aof_current_size    # AOF当前尺寸（单位：字节）
aof_base_size       # AOF上次启动和重写的尺寸（单位：字节）

自动触发时机（两个条件同时满足）：

aof_current_size>auto-aof-rewrite-min-size：当前尺寸大于重写需要尺寸

(aof_current_size-aof_base_size)/aof_base_size>auto-aof-rewrite-percentage:（增长率）当前尺寸减去上次重写的尺寸，除以上次重写的尺寸如果大于配置中的增长率

配置

appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly-${port}.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
dir /bigdiskpath #存放的路径
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失

四 RDB和AOF的选择

4.1 rdb和aof的比较

命令          rdb            aof
启动优先级      低      高(挂掉重启，会加载aof的数据)
体积           小             大
恢复速度        快             慢
数据安全性     丢数据       根据策略决定
轻重            重            轻

4.2 rdb最佳策略

rdb关掉，主从操作时

集中管理：按天，按小时备份数据

主从配置，从节点打开

4.3 aof最佳策略

开：缓存和存储，大部分情况都打开，

aof重写集中管理

everysec：通过每秒刷新的策略

4.4 最佳策略

小分片：每个redis的最大内存为4g

缓存或存储：根据特性，使用不同策略

时时监控硬盘，内存，负载网络等

有足够内存