利用永久性存储介质将数据进行保存,在在特定的时间将保存的数据进行恢复的工作机制称为持久化。
防止数据意外丢失,保证数据安全。
Redis是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。
RDB持久化和AOF持久化:前者将当前数据保存到硬盘,后者则是将每次执行的写命令保存到硬盘(类似于MySQL的binlog)。由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地。
RDB持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。
命令:save
命令可以保存数据到硬盘,默认生成dump.rdb快照文件。
dump-端口号.rdb
redis为单线程任务执行序列,save指定的执行会阻塞当前redis服务器,直到当前rdb过程完成位置,线上环境不建议使用。
命令:bgsave
,手动启动后后台执行,不会立即操作。由redis 调用fork函数生成子进程进行save操作,生成RDB文件。
bgsave是针对save阻塞问题做的优化,redis内部所有涉及到RDB操作都采用bgsave的方式,save命令可以放弃使用。
save second changes
# bgsave # 900秒:15分钟内变化一个存一次 save 900 1 # 300秒 5分钟内变了10个就存一次 save 300 10 # 1分钟内1万个变化存一次 save 60 10000
save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,对于second与changes设置通常具有互补关系,尽量不要设置行包含性关系,save配置实际是执行的bgsave操作。
方式 | save | bgsave |
---|---|---|
读写 | 同步 | 异步 |
阻塞客户端指令 | 是 | 否 |
额外内存消耗 | 否 | 是 |
启动新进程 | 否 | 是 |
解决思路
不写全数据,仅记录部分数据。(AOF,不记录数据,对所有操作进行记录,降低丢失数据风险。)
改记录数据为记录数据产生的过程
。always(每次)每次写入操作均同步到AOF文件中,数据零误差,性能较低。不建议使用
everysec(每秒)每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能较高,突然宕机的情况下最多丢失1秒内的数据。 建议使用
no(系统控制)由操作系统控制每次同步到AOF文件的周期,整体过程不可控。
#appendonly 是否开启AOF持久化功能,默认no appendonly yes #AOF写数据的策略 appendfsync always|everysec|no #自定义文件名 appendfilename filename # dir 文件路径,与RDB持久化文件保持一致就可以了
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到AOF文件的过程。简单说就是将同一个数据若干个命令执行结果转化成最终结果数据对应的指令进行记录。
作用
手动重写
bgrewriteaof
自动重写
#条件设置 auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percent # 自动重写触发对比参数(info persistence获取具体信aof_base_size息) aof_current_size aof_base_size #自动写触发条件 aof_current_size>uto-aof-rewrite-min-size (aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage percent
aof常用配置
#是否开启AOF appendonly yes # AOF文件名 appendfilename "appendonly.aof" # RDB文件和AOF文件所在目录 dir /data # fsync持久化策略 appendfsync everysec # AOF重写期间是否禁止fsync;如果开启该选项,可以减轻文件重写时CPU和硬盘的负载(尤其是硬盘),但是可能会丢失AOF重写期间的数据;需要在负载和安全性之间进行平衡 no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
## RDB与AOF的区别 | 持久化方式 | RDB | AOF | | ------------ | ------------------ | ------------------ | | 占用存储空间 | 小(数据级:压缩) | 大(指令集:重写) | | 存储速度 | 慢 | 快 | | 恢复速度 | 快 | 慢 | | 数据安全性 | 会丢失数据 | 依据策略决定 | | 资源消耗 | 高/重量级 | 低/轻量级 | | 启用优先级 | 低 | 高 | ### RDB与AOF之间的选择 * 对数据非常敏感,建议使用默认的AOF持久化 * AOF持久化策略使用everysecond,每秒钟fsync一次,该策略redis仍可以保持很好的处理性能,当出现问题是,最多丢失0-1秒内的数据 * 注意:由于AOF文件存储体积较大,且恢复速度较慢 * 数据呈现阶段有效性,件以使用RDB持久化方案 * 数据可以良好的做到阶段内无丢失(开发或运维手工维护),且恢复速度较快,阶段点数据恢复通常采用RDB方案 * 注意:利用RDB实现紧凑的数据持久化会使Redis性能降低 * 综合对比 * RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊 * 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF * 如能承受,且追求大数据的恢复速度,选用RDB * 灾难恢复选用RDB * 双保险策略,同时开启RDB和AOF,重启后,redis优先使用AOF来恢复数据,降低数据丢失的量