持久化分:
RDB, AOF
目的
为了在Redis关闭或者意外宕机的情况下,能恢复内存中的数据。
- 作为数据库使用,宕机之后恢复,这个效果很明显【但是没必要】
- 虽然Redis挂掉不会影响我们的数据本身,但是
redis重启,依然会对数据库造成瞬时压力。而且没有预热的过程。
分类
分为 RDB,AOF,下面来说说这两个的优缺点:
RDB
- 某一个时间点的快照,是全量数据集。这就意味着数据很紧凑。
- 恢复时间快。为什么呢?
RDB是一个数据点的最终数据形态【就是不会出现同一个数据的中间转换形态】RDB内部存储的就是Redis的内部数据结构编码格式【不然也就不是快照】
- 上面这个就是相对于
AOF的优点:AOF占用空间比RDB大【因为可能存在多个操作记录】AOF存储的是操作记录【有点类似WAL,只是事后日志】,需要重现操作记录才能恢复记录
- 因为是全量数据,所以备份一次其实是很慢的,如果在备份完宕机了,就会缺失这个时间段的数据
- 执行开销大。首先不能阻拦正常的主线程访问,所以就
fork(),如果数据量庞大的情况下,在fork过程中页表复制等的开销会很大
AOF
- 通过
fsync策略执行,默认一秒一次,最多丢失 2s 的数据 - 因为写入的其实是
RESP协议命令,如果误操作了如FLUSHALL,通过删除AOF文件最后的FLUSHALL,并重启redis就可以恢复到之前的数据。 - 对于相同的数据集来说,AOF 文件大小通常要大于 RDB 文件。数据恢复的比较慢
线上配置
| Config | Value | Mean |
|---|---|---|
| appendonly | yes | 开启aof |
| appendfilename | "appendonly.aof" | 文件名 |
| appendfsync | everysec | 每秒刷盘 |
| no-appendfsync-on-rewrite | yes | 在日志重写时,AOF追加只写缓存 |
| auto-aof-rewrite-percentage | 200 | AOF文件大小翻倍出发rewrite |
| auto-aof-rewrite-min-size | 64m | AOF文件触发重写的最小size |
| rdbcompression | yes | 开启RDB压缩 |
| rdbchecksum | yes | 开启RDB校验和 |
| save | Null | RDB自动触发未配置 |
| aof-use-rdb-preamble | yes | 开启混合持久化 |
对 no-appendfsync-on-rewrite 说明一下:
appendfsync 设置为 everysec 或 always ,也就意味着 AOF 执行 fsync() 刷盘时可能有阻塞性能问题。为了减轻这个问题,设置这个值 yes,在日志重写时,主进程不进行命令追加的刷盘操作,而只是将其放在缓冲区里,避免与重写造成DISK IO上的冲突,如果在重写过程中,redis 宕机丢失的数据就是整个重写过程数据。
未完待续。。。