Redis持久化

前言

话不多说直奔主题…

RDB

主要触发机制

save

cli命令: save

文件策略: 如果存在老的RDB文件,新的将其替换掉

时间复杂度: O(n)

我们把客户端和服务端用一个图来表示,save时会帮我们生成一个RDB文件

由于它是同步命令,并且在单线程中执行,在数据量非常多的时候,此时执行save命令,他会将数据进行完整拷贝,可能会造成redis阻塞。

bgsave

通过在后台fork一个子进程完成复制

自动

根据REDIS配置定时同步数据到RDB文件

配置SecondsChanges
save9001
save30010
save6010000

eg:60秒中改变了10000次会发生备份RDB

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

  • 全量复制
  • Debug Reload
  • shutdown

save or bgsave ?

命令savebgsave
IO类型同步异步
阻塞发生在fork时
复杂度O(N)O(N)
优点不会消耗内存不阻塞客户端命令
缺点阻塞客户端命令消耗内存

### 配置
1
2
3
4
5
6
7
8
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error yes //bgsave出现问题会停止写入
rdbcompression yes //压缩模式
rdbchecksum yes //对RDB进行校验和检验


#### 最佳配置
1
2
3
4
5
dbfilename dump-${port}.rdb
dir bigdiskpath //选择大的硬盘
stop-writes-on-bgsave-error yes //bgsave出现问题会停止写入
rdbcompression yes //压缩模式
rdbchecksum yes //对RDB进行校验和检验


### 小结
RDB是Redis内存到硬盘的快照,用于持久化 save通常会阻塞Redis
bgsave不会阻塞Redis,但是会fork子进程 save自动配置满足其一就会被执行
* 有些触发机制不容忽视

### RDB问题

耗时耗性能
> O(N)数据耗时

> fork耗内存

> Disk I/O:IO性能

不可控丢失数据
时间戳save
T1执行多个命令
T2满足RDB自动创建条件
T3再次执行多条命令
T4宕机

宕机会发生数据丢失

AOF

三种策略

everysec

always

同everysec流程,只不过always会把每条命令都写入到AOF文件中

no

由操作系统来决定是否刷新

比较

命令alwayseverysecno
优点不丢失数据每秒一次fsync丢1秒数据不用管理
缺点IO开销比较大丢1秒数据不可控

### AOF重写

#### 作用

减少硬盘占用量 加快回复速度

### 重写两种方式

#### bgrewriteaof

命令:bgrewriteaof



重写配置
配置名含义
auto-aof-rewirte-min-sizeauto-aof-rewirte-percentage
AOF文件重写尺寸AOF文件增长率

统计
统计名含义
auto-current-sizeauto-base-size
AOF当前尺寸AOF上次启动和重写的尺寸

#### 自动触发时机

auto-current-size > auto-aof-rewirte-min-size (auto-current-size - auto-base-size) / auto-base-size > auto-aof-rewirte-percentage

### AOF重写流程



### 配置

appendonly yes appendfilename “appendonly-${port}.aof”
appendfsync everysec dir /bigdisk
no-appendfsync-on-rewrite no //aof重写失败是否允许丢失数据 auto-aof-rewrite-percentage 100 //增长率
* auto-aof-rewrite-min-size 64mb //最小尺寸

## RDB 和 AOF 抉择
命令RDBAOF
启动优先级
体积
恢复速度
数据安全性丢数据根据策略决定
轻重
-------------本文结束感谢您的阅读-------------