Redis的持久化
Redis的持久化（RDB、AOF）：
* 对于故障恢复数据
RDB快照：每隔几分钟（5分钟）或者几小时同步一个RDB文件，都是全量
优点：
1. 类似快照，适合做冷备份（由redis本身自己控制多久去生成文件），存储于云端（阿里云）
AOF也可以做冷备份，但是需要自己写脚本
1. 对Redis读写影响非常小，保持Redis的高性能
RDB每次知己写到内存，少数情况写到磁盘
AOF写文件，虽然可以很快写到os cache中，但是有时间开销，还是满于RDB
1. 相比AOF，RDB恢复数据速度更快
AOF存放的是指令日志文件，需要全部执行
RDB存放的直接是数据文件，直接加载到内存中
缺点：
1. 如果redis宕机了，由于RDB间隔5分钟同步数据，那么会丢失这个5分钟的数据
2. RDB创建子进程fork进行rdb快照文件时，文件过大，那么会导致客户端停止服务数毫秒或秒
AOF：
1. 每个命令日志都会先写入os cache中，然后再从os cache中到disk file；redis每隔1s，调用一次os的fsync操作，强制将os cache中的数据刷入磁盘文件
2. Redis只有一个AOF文件，内存是有限的所以AOF不会一直增大，满了以后执行淘汰算法，LRU，自动淘汰一些数据从内存中清除
3. AOF存放每一条命令，过大后执行rewrite操作，基于但是redis内存中的数据，重构一个更小的AOF，过大的删除
4. 顺序：redis内存满了（100W）AOF=100w ->LRU后（内存50w，AOF=100w）->继续写操作(内存100w)AOF=150w ->AOF过大创建新的小AOF（基于redis内存中的最新的100w创建）后删除大的AOF
优点：
1. AOF可以更好的保护数据不丢失，一般每1s通过后台线程执行一次fsync，数据最多丢失1s，保证os cache的数据写入磁盘
2. AOF日志文件以append_only模式写入，没有磁盘寻址的开销，写的性能高，文件不容易损坏
3. AOF文件过大，出现后台重写操作，不影响客户端读写，有rewrite操作
4. 适合灾难级别的紧急数据恢复，比如不小心用了flushall清空数据，只要rewrite操作还没有发生，可以把复制一个AOF文件，最后一条flushall命令删掉，再把AOF放回去，就可以通过恢复机制，自动恢复所有数据
缺点：
1. 对于同一份文件来说AOF日志文件比RDB文件大
2. AOF开启后，支持写的QPS比RDB的低，因为每秒执行fsync操作一次日志文件，当然性能还是很高的
RDB和AOF不单独使用：
* 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为恢复数据的第一选择；
* 用RDB来做冷备份，在AOF文件丢失或者损坏的时候，可以用RDB文件做快速恢复数据
原文地址：https://blog.csdn.net/qq_44338332/article/details/145115153
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！