redis 数据持久化

redis所有数据保存到内存中，对数据的更新将会异步的持久化到硬盘上面
因为内存数据库的原因，数据容易丢失，所以，持久化是必须的。

redis 持久化两种

1. 保存二进制文件 比如 redis rdb文件
2. 写日志： redis AOF 文件

关于 RDB

1. 什么是RDB
2. 触发机制
3. 重点

rdb文件保存二进制
触发机制 --主要 3种方式

1. save(同步）
2. bgsave(异步)
3. 自动

直接在命令行执行 save，会造成 redis 的阻塞。

如果有老的RDB文件，会替换掉它

如果是执行 的 bgsave

命令	save	bgsave
IO类型	同步	异步
阻塞	yes	yes(但是阻塞在fork)
优点	不消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork, 消耗内存

当redis 的写操作非常频繁的时候，会不停的 copyOnWrite,

要执行 RDB的话，你需要敲 save 或者 bgsave的命令，当然，redis其实提供了自动 生成 rdb文件的策略

save	seconds	changes
save	900	1
save	300	10
save	60	10000

如果redis 写操作太频繁的话，频繁 save操作，会对硬盘造成一定的压力

rdb文件 默认是 dump.rdb

触发RDB的条件

1. 全量复制 (主从复制)
2. debug reload ()
3. shutdown

debug reload
save当前的rdb文件，并清空当前数据库，重新加载rdb，加载与启动时加载类似，加载过程中只能服务部分只读请求（比如info、ping等）

使用 info memory 可以查看redis 内存使用情况
一帮不会用 save的自动配置

RDB是有一些问题的，
比如 耗时、耗费性能
不可控，丢失数据
使用 bgsave,会 fork一个子进程，疯狂的 copy-on-write的策略，不适合大量的写操作情况

丢失数据的话：举个例子，保存了数据到 rdb文件，这个时候，又往redis 上写数据，还没有把新数据写入到 rdb文件里面，如果服务器挂了，就丢失了新数据了。

使用 AOF的话，会在日志里面不停追加命令，这种就不会丢失数据

3种策略

命令	always	everysec	no
缺点	IO开销大	丢失1秒的数据	不可控
优点	不丢数据	每秒一次 fsync 丢1秒数据	不知道

通常会使用 eversec 的使用 允许只丢失1秒数据

AOF重写

比如 两次 incr num —> 优化为 set num 2
set hello 1 ; set hello 2 —> 优化为 set hello 2
这种可以做到加快恢复速度 还有减少磁盘的占用量