redis持久化机制及原理

一、redis持久化
redis提供两种持久化策略 rdb 和 aof
rdb持久化策略：按照规则 定时将内存冲的数据同步到磁盘
1、快照
redis 在指定情况下会触发快照
1）、自己配置的规则
redis.conf中如下配置 save seconds changes
save 900 1 --当900秒内 更改的key数量大于1 时 执行快照备份
save 300 10 --当300秒内 更改的key数量大于10 时 执行快照备份
save 60 10000 --当60秒内 更改的key数量大于10000 时 执行快照备份
2 ）、save 活着bgsave
命令 save 执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求
命令 bgsave 在后台异步执行快照操作，这个操作不会阻塞客户端请求
3）、执行flushall 的时候
清楚内存中所有数据，只要规则不为空（1中配置的规则不为空）redis会执行快照
4 ）、执行复制的时候
复制数据到从节点的时候
快照的实现原理
redis 会使用fork函数复制一份当前进程的副本（子进程），fork进程负责把内存中的数据同步到磁盘的临时文件
父进程继续处理客户端请求

优点：
1）可以最大化redis的性能
缺点：
1）、会有数据丢失，两次快照触发规则之间的数据变动 可能会丢失

2、aof持久化策略：每次执行命令后，把命令本身记录下来
aof会把redis执行的每一条命令追加到磁盘文件中。
优点 记录了每次的操作日志，数据恢复比rdb方式更完整。
缺点 备份每次客户端的操作，对redis 的性能会有一定的影响 可以考虑使用ssd固态硬盘

aof持久化方式的开启方式 在redis.conf 中配置 :appendonly yes （默认可能为no）
appendfilename “appendonly.aof” （该项配置配置aof文件的名称 会写在bin目录下）
修改完配置，启动redis 并执行如下 命令

OK
127.0.0.1:6379> set key value
OK
127.0.0.1:6379> set key val1
OK
127.0.0.1:6379> 

然后bin目录下 vi appendonly.aof 可以看到文件中 记录的命令日志

[root@192 bin]# vi appendonly.aof 
*2
$6
SELECT
$1
0
*1
$8
flushall
*3
$3
set
$3
key
$5
value
*3
$3
set
$3
key
$4
val1
~

默认情况下aof文件中会记录 所有的命令
压缩策略配置 压缩会对同一个键的操作进行优化。
auto-aof-rewrite-percentage 100 表示当前aof文件超过上次aof文件大小百分之多少的时候会进行重写。如果之前没有重写过以启动时文件大小为准
auto-aof-rewrite-min-size 64mb 表示限制允许重写最小aof文件大小。文件大小小于这个值时不用进行优化
aof 重写的原理过程：
redis在后台自动对aof文件重写。这个过程是安全的。客户端依然可以发起请求。
执行aof重写时现有的aof文件会继续追加命令日志，新建一个aof临时文件去做重写。

redis 每次更改数据的时候，aof机制会将命令记录的aof文件。但是由于计算机硬件也并不是直接将文件写入到磁盘，而是通过缓存写入，所以如果数据还在缓存时宕机也会存在数据丢失问题。

缓存数据同步到磁盘的时机也可以在redis.conf 中配置如下：

# appendfsync always    每次有redis命令都同步，性能最低，安全性最高
appendfsync everysec   每秒同步一次
# appendfsync no      不主动执行同步操作 由操作系统执行。这个是最快但是最不安全的

aof文件损坏如何修复：
通过 redis-check-aof -fix 命令进行修复。

两种持久化策略可以同时使用也可以使用一种。如果同时使用redis有限使用aof文件来回复数据。