16.redis持久化

持久化的作用

什么是持久化

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

持久化的实现方式

快照，某时某点的完整数据备份
写日志，数据库任何更新操作写日志

RDB

什么是RDB

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

save(同步)

生成文件策略，如果存在老的RDB文件，新替换老，会先生成一个临时文件，然后替换，时间复杂度O(n)

bgsave(异步)

bgsave的fork过程通常是非常快的，但还是会阻塞redis，阻塞发生在fork
生成文件策略，如果存在老的RDB文件，新替换老，会先生成一个临时文件，然后替换，时间复杂度O(n)
save和bgsave的比较

命令	save	bgsave
IO类型	同步	异步
阻塞	是	是(阻塞发生在fork)
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork，消耗内存

自动

满足任何一个条件，

配置	seconds	changes
save	900	1
save	300	10
save	60	10000

配置

配置	说明
save 900 1
save 300 10
save 60 10000	对应上面自动方式的三个条件
dbfilename dump.rdb	rdb文件叫什么名字
dir ./	rdb、aof、日志文件存储位置
stop-writes-on-bgsave-error yes	保存rdb文件出错是否停止写
rdbcompression yes	rdb文件是否采用压缩的格式
rdbchecksum yes	是否对rdb进行校验

最佳配置

关闭自动生成

配置	说明
dbfilename dump-${port}.rdb	rdb文件叫什么名字
dir /bigdiskpath	rdb、aof、日志文件存储位置
stop-writes-on-bgsave-error yes	保存rdb文件出错停止写
rdbcompression yes	rdb文件采用压缩的格式
rdbchecksum yes	对rdb进行校验

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

全量复制
debug reload
shutdown

AOF

RDB现存问题

1. 耗时、耗性能
   O(n)数据，耗时
   fork()消耗内存，虽然使用copy-on-write策略
   Disk I/O，IO性能
2. 不可控、丢失数据

时间戳	save
T1	执行多个写命令
T2	满足RDB自动创建的条件
T3	再次执行多个写命令
T4	宕机

则T3 数据丢失

什么是AOF

用两张图分别看下创建AOF、和从AOF中恢复数据

AOF三种策略

always

everysec

no

三种策略比较

策略	always	everysec	no
优点	不会丢失数据	每秒一次fsync，丢一秒数据	不用管
缺点	IO开销较大，一般的sata盘只有几百TPS	丢一秒数据	不可控

AOF重写

AOF策略可以将每条命令都写入AOF文件中，随着命令持续写入、时间的推移、或者并发量增大，AOF会逐渐增大，恢复的话，会非常慢，随着文件无线增大，无论是磁盘管理，还是写入文件速度，都会有一定影响，所以提供了AOF策略来解决这个功能

AOF作用

AOF重写，就是把过期的、没有用的、重复的、一些可以优化的命令进行化简成一个小的AOF文件，来达到如下目的

1. 减少磁盘占用量
2. 加速恢复速度

AOF重写实现两种方式

bgrewriteaof命令

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
同时满足，会触发

AOF重写流程

执行bgrewriteaof命令的时候，如果当前有进程正在执行AOF重写，那么直接返回；如果有进程正在执行bgsave，那么等待bgsave执行完毕再执行AOF重写。
Redis主进程会fork一个子进程执行AOF重写，开销和RDB重写一样。
AOF重写过程中，不影响Redis原有的AOF过程，包括写消息到AOF缓存以及同步AOF缓存中的数据到硬盘。
AOF重写过程中，主进程收到的写操作还会将命令写到AOF重写缓冲区，注意和AOF缓冲区区分开。
由于AOF重写过程中原AOF文件还在陆续写入数据，所以AOF重写子进程只会拿到fork子进程时的AOF文件进行重写。
子进程拿到原AOF文件中的数据写道一个临时的AOF文件中。
子进程完成AOF重写后会发消息给主进程，主进程会把AOF重写缓冲区中的数据写道AOF缓冲区，并且用新的AOF文件替换旧的AOF文件。

配置

appendonly yes
appendfilename “appendonly-${port}.aof”
appendfsync everysec
dir /bigdiskpath
no-appendfsync-on-rewrite yes
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100

RDB和AOF的抉择

RDB和AOF比较

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

RDB最佳策略

1. 建议关闭RDB
   无论是Redis主节点，还是从节点，都建议关掉RDB。但是关掉不是绝对的，主从复制时还是会借助RDB。
2. 用作数据备份
   RDB虽然是很重的操作，但是对数据备份很有作用。文件大小比较小，可以按天或按小时进行数据备份。
3. 主从，从开？
   在极个别的场景下，需要在从节点开RDB，可以再本地保存这样子的一个历史的RDB文件。虽然从节点不进行读写，但是Redis往往单机多部署，由于RDB是个很重的操作，所以还是会对CPU、硬盘和内存造成一定影响。根据实际需求进行设定。

AOF最佳策略

1. 建议开启AOF
   如果Redis数据只是用作数据源的缓存，并且缓存丢失后从数据源重新加载不会对数据源造成太大压力，这种情况下。AOF可以关。
2. AOF重写集中管理
   单机多部署情况下，发生大量fork可能会内存爆满。
3. everysec
   建议采用每秒刷盘策略

最佳策略

1. 小分片
   使用maxmemary对Redis最大内存进行规划。
2. 缓存和存储
   根据缓存和存储的特性来决定使用哪种策略
3. 监控（硬盘、内存、负载、网络）
4. 足够的内存
   不要把就机器全部的内存规划给Redis。不然会出很多问题。像客户端缓冲区等，不受maxmemary限制。规划不当可能会产生SWAP、OOM等问题。