02-Redis持久化

Redis 持久化

RDB

描述：快照持久化，将redis内存中所有的数据一次性同步到名字为 dump.rdb 的二进制文件中。

配置文件：redis.conf 文件中 设置rdb的存储模式，代表60 秒内有至少有 1000 个键被改动，及进行一次rdb同步，可以同时设置多个策略

# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可

使用:redis客户端执行命令save或bgsave可以生成dump.rdb文件

save和bgsave区别以及默认的形式：
配置文件中默认是以bgsave形式进行同步数据

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其它命令	是	否
优点	不会消耗额外内存	不会阻塞客户端命令
缺点	阻塞客户端命令	消耗额外的内存

（了解）bgsave的写时复制(COW)机制
Redis 借助操作系统提供的写时复制技术（Copy-On-Write, COW），在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那
么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

AOF

配置文件：AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)

配置文件：redis.conf 文件中，默认是关闭aof，和 每秒fsync一次

appendonly yes #开启aof
appendfilename "appendonly.aof" #设置aof的文件名字

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

appendonly文件形式：

# select 0
*2 
$6
SELECT
$1
0
# set age 666666 三条语句所以是*3 $3代表有三个字符（set）
*3
$3
set
$3
age
$6
666666

AOF重写:
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
例如：原子加了六次incr count 将被优化为 set count 6

 auto‐aof‐rewrite‐min‐size 64mb #aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
 auto‐aof‐rewrite‐percentage 100 #aof文件自上一次重写后文件大小增长了100%则再次,触发重写（64重写后，第二次为128）

以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF，异步重写

混合模式

描述: 因为aof的数据比较全，所以在恢复时会优先使用，但是aof的文件不是二进制文件，在数据大的情况下恢复的比较慢。混合模式就是其优化。主要是在重写的时候，重写时将已存在的数据改为二进制的形式保存。但是之后新增的依然用指令的形式。新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。重启的时候就可以先加载二进制形式的数据再执行指令。大大提高了效率

配置文件：
因为基于aof，所以手动重写指令bgrewriteaof也可以使用。aof策略也由aof的配置生效

appendonly yes #开启aof 前提
aof‐use‐rdb‐preamble yes # 开启混合

持久化选择

4.0的混合模式是aof的优化