世间两朵相似的花-Redis的持久化策略RDB与AOF

世间两朵相似的花

"如果有转世我们的世界将会是怎么样，爱因斯坦将会续上一世为世界做出更多贡献？"

如果把Redis看作一个人，整个系统就是一个世界，那么这个世界就有转世这一说。

Redis在短暂的一生中因意外而亡，然而我们需要它继续站起来为我们工作，这一方世界离不开Redis。Redis为自己的这一世记录所有的记忆，只为了在重获新生时续上一世的记忆重新完成自己的使命，但意外总是来得比较突然，最后一刻也许会来不及记录意外就来了，当重生时它还是原来的自己吗？也许并不是，也或许是，严谨的说，或许只是世间两朵相似的花罢。

为什么Redis需要持久化策略？

缓存就像我们的记忆，忘了就得重新再记一遍。写磁盘就像做笔记，是为了我们忘记一件事情时能通过笔记重新回忆起来。Redis如果故障重启，就和人事故失忆一样，故障前的记忆都被忘记了，所以我们需要一个重新拾回记忆的方案，所以Redis准备了持久化策略，让Redis即使故障也能通过"笔记"重拾回忆，续上一世继续完成它的使命。

Redis的持久化策略有两种：

一、RDB(Redis Database)

1.概括:在单位时间间隔内将该时间点的数据集写入磁盘。

 

2.执行过程

Redis会fork(OS函数，复制进程)一个子进程(子进程与主进程一致)来进行持久化，将数据写到临时文件中（全量数据），等到子进程将临时文件写完时，再用这个临时文件替换原有的rdb文件，主进程在此过程中无需做任何I/O操作，保障了Redis的高性能。

3.优点与缺点

1.比起AOF来说，RDB的优点是比较高效、恢复速度较快。

2.节省磁盘空间。

缺点：

1.最后一段时间内如果有新数据写入并且故障将会丢失这段时间内的数据。

2.在fork子进程时需要2倍的内存。

4.如何使用

#redis默认配置，默认开启RDB
#   save ""
 
save 900 1  #900秒内如果有1个key值change就执行save指令
save 300 10 #300秒内如果有10个key值change就执行save指令
save 60 10000 #60秒内有10000个key值change就执行save指令

​
#关闭RDB
save ""
 
#save 900 1 
#save 300 10
#save 60 10000

​

5.适用场景

如果对数据完整性要求很高不适合使用(丢失最后一段时间内未保存的数据)，RDB比较适合数据的大规模恢复。

二、AOF(Append Only File)

1.概括：在Redis执行写操作(set、del等)，不包括读操作(get等)，以日志的形式记录此操作，并将其append到文件中，Redis重启时会把记录下来的文件全部再执行一遍，以达到"转世"的目的。

2.执行过程

1.追加命令至AOF缓冲区

2.根据配置appendfsync策略来将AOF缓冲区的数据写到AOF文件中

3.AOF超过配置AOF文件重写大小时(auto-aof--rewrite-min-size设置最小从写size，auto-aof-rewrite-percentage设置重写百分比)，开始rewrite AOF文件，例如set k1 v1,del k1；这种语句就可以丢弃。

关于rewrite的重写时机特别说明:假设auto-aof--rewrite-min-size=100M，auto-aof-rewrite-percentage=100%，那就是当AOF文件大小 > 100M + 100M * 100%时，就会进行rewrite。

3.优点与缺点

优点：

1.AOF比起RDB来说明显AOF对数据的保障性更高，即丢失数据较少(根据appendfsync策略决定)，在always的情况下，最多丢失一秒钟的数据。

缺点：

1.AOF效率较低，且AOF文件通常比较大。

2.需要配合RDB一起使用，官网指名单独使用AOF可能出现BUG

4.AOF文件修复

如果在append过程中故障，可能会出现文件不完整的情况(最后一行指令本来应该是set k1 v1，但故障时只写入se)，此时需要修复文件，请使用redis-check-aof --fix appendonly.aof命令来修复文件

5.如何使用 

#是否开启aof----no:不开启,yes：开启
appendonly no

#始终同步，每次Redis的写操作会被立刻同步至AOF文件
appendfsync always 
#每秒同步一次，AOF缓冲区内的数据被每秒一次提交到AOF文件中(可能丢失一秒的数据)
# appendfsync everysec
#Redis不主动同步，把同步时机交给操作系统
# appendfsync no

#重写比例，e.g 64mb + 64mb * 100%(设置为0%关闭重写功能)
auto-aof-rewrite-percentage 100
#重写最小文件大小 
auto-aof-rewrite-min-size 64mb

6.使用场景 

对数据完整性要求较高可以使用，且与RDB配合使用。

---------------------------------------------------------------------------------------------------------------------------------

如果AOF与RDB都开启Redis用RDB文件还是AOF文件？

Redis用的是AOF文件来恢复数据，毕竟AOF方式的数据比RDB的数据要完整。

---------------------------------------------------------------------------------------------------------------------------------

总结：

如果只做缓存功能，对数据丢失与否无所谓，就关闭RDB与AOF。

如果对丢失数据量稍多一点也无所谓，那就使用RDB。

如果对丢失数据无法忍受，那就开启AOF与RDB共舞~

尾声

Redis重获新生，但却与前世大同小异(不走运丢失了小笔数据)，那也不错，就请带着上一世的"记忆"在这一世中绽放出更璀璨的光芒！