Redis持久化

RDB快照(snapshot)

在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。

save 60 1000 表示60s内有1000次命令，我们关闭RDB只需要将所有的save保存注释掉即可

我们还可以手动执行命令生成RDB快照，进入Redis客户端执行命令save或bgsave可以生成dump.rdb，每次命令执行都会将所有Redis内存快照到一个新的rdb文件中，并且覆盖原有的rdb快照文件。

缺点: 如果服务器突然宕机，RDB快照会造成数据丢失。

bgsave写时复制机制

bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据。

子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件，此时如果主线程对这些数据都是读操作，那么主线程和bgsave子线程相互不影响。但是，如果主线程要修改一块数据，那么这块数据就会被复制一块，生成该数据的副本，然后bgsave子进程会把这个副本数据写入RDB文件中，而在这个过程中，主线程仍然可以直接修改原来的数据。

如果配置自动生成rdb文件之后,后台使用的方式就是bgsave

save和bgsave对比

命令	save	bgsave
IO类型	同步	异步
是否阻塞Redis其他指令	是	否(生成子进程执行调用fork函数时会有短暂阻塞)
复杂度	O(N)	O(N)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

AOF

AOF快照功能并不是非常持久，如果Redis因为某些原因而造成故障停机，那么服务器将会丢失最近写入，且仍未保存到快照的数据。

从版本1.1开始，Redis增加了一种完全持久的方式；AOF持久化，将修改的每一条指令记录在文件appendonly.aof中(先写入OS Cache，每隔一段时间fsync到磁盘)

可以看下下面appendonly.aof文件

对于如何打开AOF功能,可以在配置文件中加入 appendonly yes

AOF和RDB的区别

持久化方式	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定

注意：在生产环境，RDB和AOF可以都启用，Redis启动时如果既有aof文件又有rdb文件，会优先选择aof文件来恢复数据，因为aof一般来说数据更安全一点。

Redis4.0混合持久化

当重启Redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常会使用AOF日志重放，但是重放AOF日志性能相对于RDB来说要慢很多，这样在Redis实例很大的情况下，启动需要花费很长的时间。

Redis4.0为了解决这个问题，带来了一个新的持久化选项：混合持久化。

我们可以通过在配置文件中先开启AOF,然后在开启混合持久化

appendonly yes
aof-use-rdb-preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件中去了，而是将重写这一刻前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件中，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件之后才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。