Redis持久化

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

rdb (Redis DataBase)

流程图

相关配置回顾

save

保存的文件是dump.rdb

stop-writes-on-bgsave-error

当Redis无法写入磁盘的话，直接关掉Redis的写操作。

推荐yes

rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

• 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。

推荐yes

rdbchecksum 检查完整性

在存储快照后，还可以让redis使用CRC64算法来进行数据校验

• 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

推荐yes

redis备份

在服务器启动的时候,先备份一下dump.rdb

cp dump.rdb dump2.rdb

然后删除掉dump.rdb 模拟一下数据丢失的实际场景 关闭redis服务器 接下来要怎么恢复原来的数据呢,我们只需要 cp dump2.rdb dump.rdb 启动Redis,备份数据会直接加载

• 简单说就是先备份一下rdb文件 , 然后需要重新加载的时候再改回原来的默认名字就好了 , redis就会自动重新加载

优点

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

缺点

最后一次持久化后的数据可能丢失。

比如说 我们设置了save 20 3 20秒内如果有3个key发生变化就会去持久化操作写入文件
那假如说,现在我们第一个20秒已经设置3个了,存进去了
而第二个20秒,我们设置了2个,这时服务器突然挂掉了,那是不是就不会进行持久化了(因为还没有达到3个的条件),然后我们刚才设置的那两个也就自然而然没有进行持久化,就造成了数据丢失

AOF(Append Only File)(流程还没看)

默认不开启

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

​

重写

重写只关心最终的结果,不关心你的过程,把两条语句压缩成一条了 ​

auto-aof-rewrite-percentage：

设置重写的基准值，(文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：

设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
如果Redis的AOF当前大小>= base_size base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

缺点

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

建议

官方推荐两个都启用。

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

• 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段

如果对数据不敏感，可以单独用RDB。 如果只是做纯内存缓存，可以都不用。

这篇好文章是转载于：学新通技术网