这是我参与8月更文挑战的第31天,活动详情查看:8月更文挑战
前言
我认为
Redis
之所以会成为大家首选的缓存数据库的原因,第一是开源易用,第二则是我一直低估了的第二大优势,它支持数据持久化。
持久化
Redis
所有的数据都保存在内存中,我们都知道,内存中的数据一旦关机,或者断电故障,数据就会被清空。为了防止数据丢失,Redis
在将数据保存到内存中的时候,会异步的将数据保存到硬盘上。常见的持久化方案有两种,一种是快照,另一种为写日志。
快照(RDB)
将内存中所有的数据保存起来,存放在硬盘上,类似于MySQL数据库的备份。
reids
创建RDB
二进制文件,并且创建快照的过程中是通过覆盖的形式redis
启动时重新载入RDB
二进制文件
触发方式
- save 同步保存
- bgsave 异步保存
- 通过配置项,自动保存
RDB的配置项
# 自动保存策略,`60`秒内有一个`key`发生变化就自动保存
save 60 1
# rdb文件名
dbfilename dbdump.rdb
# rdb文件保存目录
dir ./
# 发生错误中断写入,建议开启
stop-writes-on-bgsave-error yes
# 数据文件压缩,建议开启
rdbcompression yes
# 开启crc64错误校验,建议开启
rdbchecksum yes
RDB的缺点
数据量越大,越耗时,耗费性能
日志(AOF)
将Redis运行过程中所有的执行命令记录全部保存下来,当我们需要恢复时,将所有命令按照顺序执行一遍。
实现方式
每次执行完命令,在
AOF
文件中追加日志,恢复的时候载入AOF
文件,恢复数据 AOF的追加(fsync)策略
- always 随时写入
- 优点:不丢失数据
- 缺点:
IO
开销较大,一般的sata
盘只有几百TPS
- everysec 每秒写入 推荐
- 优点:每秒一次
fsync
,降低了开销- 缺点:会丢
1s
的数据- no 依赖
os
规则写入
- 优点:没有
- 缺点:不可控
AOF重写
对一些重复操作,会进行处理,只关注最终的状态,减少了执行的时间。举个例子,原生的
AOF
按顺序记录了set hello java , set hello vue
重写后AOF
就是set hello vue
实现方式
bgrewriteof
命令AOF
重写配置
AOF配置
# 开启aof
appendonly yes
# aof日志文件名
appendfilename aof-3306.aof
# 每秒记录一次日志
appendfsnc everysec
# 重写过程中是否向日志文件中写入
# yes 带表rewrite过程中,不向aof文件中追加信息,rewrite结束后再写入
# no 带表rewrite执行的同时,也向aof追加信息
no-appendfsync-no-rewrite yes
# 触发重写文件增长百分比,默认100%
auto-aof-rewrite-percentage 100
# 触发重写最小aof文件大小
auto-aof-rewrite-min-size 64mb
扩展
Reids
是单线程模型
为什么使用单线程?
- 内存处理的速度足够快,纳秒级别的处理速度。
- 非阻塞
IO
,IO
多路复用,基于时间完成读写- 避免线程切换与资源竞争
注意事项
正因为单线程的特性,一次只能运行一条命令,所以一些执行慢的命令需要谨慎使用。比如
keys/flushall/flushdb/exec/save/bgsave/...