Redis持久化怎么实现的？

11.1.简介

数据存放于：

内存：高效、断电（关机）内存数据会丢失

硬盘：读写速度慢于内存，断电数据不会丢失

11.2.RDB

8月  23  20:26 bin

8月  31  12:09 dump.rdb

8月  23  20:30 redis.conf

RDB:是redis的默认持久化机制。RDB相当于照快照，保存的是一种状态。几十G数据----》几KB快照**

快照是默认的持久化方式。这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。

优点：

快照保存数据极快、还原数据极快，适用于灾难备份

11.3.AOF

由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式

 

Append-only file:aof 比快照方式有更好的持久性，是由于在使用aof持久化方式时，redis会将每一个收到的写命令都通过write 函数追加到文件中（默认是appendonly.aof）。当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

 

有三种方式如下（默认是：每秒fsync 一次）

- appendonly yes //启用aof持久化方式

- #appendfsync always  //收到写命令就立即写入磁盘，慢慢，但是保证完全的持久化

- appendfsync everysec  //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中

- #appendfsync no //完全依赖os，性能最好，持久化没保证

缺点：

小内存机器不适合使用，RDB机制符合要求就会快照

快照条件：

​         1、服务器正常关闭时  ./bin/redis-cli shutdown

​         2、key满足一定条件，会进行快照

vim redis.conf  搜索save

:/save

save 900 1   //每900秒（15分钟）至少1个key发生变化，产生快照

save 300 10 //每300秒（5分钟）至少10个key发生变化，产生快照

save 60  10000  //每60秒（1分钟）至少10000个key发生变化，产生快照

产生的问题：

aof的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test 命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。