redis由浅入深(二) --持久化

1.redis的持久化方式

• RDB快照
• AOF日志

2.RDB快照配置参数

save 900 1                900秒至少有1个key被更改时才会触发生成快照

save 300 10             300秒至少有10个key被更改时才会触发生成快照

save 60 10000        60秒至少有10000个key被更改时才会触发生成快照

stop-writes-on-bgsave-error yes              后台存储操作失败则停止写操作

rdbcompression yes        启用LZF压缩

rdbchecksum yes            存储和加载RDB文件时校验

dbfilename dump.rdb      设置RDB存储文件名称

dir ./     工作目录，RDB存储在该目录

3.AOF日志配置参数

appendonly no      是否启用AOF日志持久化appendfilename  "appendonly.aof"   默认AOF文件名称

appendfsync no 系统缓冲,统一写,速度快

appendfsync alway   系统不缓冲,直接写,慢,丢失数据少

appendfsync  everysec 默认配置，每秒写一次

no-appendfsync-on-rewrite no   当主进程在进行向磁盘的写操作时，将会阻止其它的fsync调用

auto-aof-rewrite-percentage 100   AOF文件触发自动rewrite的百分比，值为0则表示禁用自动rewrite

auto-aof-rewrite-min-size 64mb    AOF文件触发自动rewrite的最小文件size

aof-load-truncated yes  是否加载不完整的aof文件来进行启动

4.RDB持久化方式优缺点

• 优点：RDB文件比较紧凑，保存了某个时间点的数据集，适用于数据集备份，可传送到远端数据中心，并且可作为容灾；RDB保存文件时父进程唯一需要做的就是fork出一个子进程，由子进程来做RDB持久化，父进程不需要做其他的IO操作，最大化了redis的性能
• 缺点：当Redis意外宕机，Redis丢失的数据相对AOF较多；父进程fork子进程保存数据集，如果数据集较大时，fork会非常耗时，可能会导致Redis不能响应客户端

5.AOF持久化方式优缺点

• 优点：耐久性，根据业务的需求你可以选择不同的fsync策略；AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题；当AOF文件过大时，自动地在后台对 AOF 进行重写，重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合，而且整个重写操作是绝对安全的；AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松
• 缺点：对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积；根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB