Redis持久化方案
RDB Redis DataBase;
AOF Append Only File;
RDB是redis默认的持久化方案 , 满足一定的条件的时候,会把当前的数据写入磁盘,生成一个快照文件dump.rdb ;
redis重启会通过加载dump.rdb文件恢复数据 ;
RDB实现持久化:
RDB按照规则来触发持久化存储的 , 在redis.config中我们可以看到以下几个配置:
save 900 1 # 900秒内至少有一个key被修改(包括添加)
save 300 10 # 300秒内至少有10个key被修改
save 60 10000 60秒内至少有10000个key被修改
注意 : 这几个配置不冲突,只要满足一个就会被触发 ;
RDB的优点:
1. RDB是一个紧凑的单一文件,很方便;
2.与AOF相比,恢复大数据的时候,RDB稍微快一些 ;
RDB的缺点:
1.没有办法做到实时/秒持久化 ; 原因:因为运行的成本较高,每次运行bgsave都要执行fork操作创建的子进程 ;
2.一定的间隔时间内做一次备份,如果redis意外down掉,会丢失最后一次快照之后的所有修改, 如果数据比较重要可以使用AOF进行持久化;
AOF持久化：
Redis 默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到AOF文件中。Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
AOF数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存;
AOF的保存规则:
# appendfsync always
# appendfsync everysec
# appendfsync no
AOF 持久化策略（硬盘缓存到磁盘），默认 everysec
no 表示不执行 fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
always 表示每次写入都执行 fsync，以保证数据同步到磁盘，效率很低；
everysec 表示每秒执行一次 fsync，可能会导致丢失这 1s 数据。通常选择 everysec ，兼顾安全性和效率。
AOF方式的优点 :
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis最多也就丢失 1 秒的数据而已。
AOF方式的缺点:
对于具有相同数据的的Redis，AOF文件通常会比RDF文件体积更大（RDB存的是数据快照）。
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。
文件越来越大，怎么办？
由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF恢复要求时间越长。
可以使用命令 bgrewriteaof来重写。AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件 ;