redis持久化

rdb:根据配置文件中的配置每个一段时间监测到一定数量的键变化了，就把内存中的数据快照到磁盘文件中；可用save/bgsave手动触发

不可以把备份文件dump.rdb和生产redis服务器放在同一台机器上，必须分开各自存储，以防生产机物理损坏后备份文件也挂了

在linux程序中，fork（）会产生一个和父进程完全相同的子进程，子进程在此后会exec系统调用，出于效率考虑，尽量避免彭胀

rdb优点：
适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性要求不高
RDB文件在内存中的加载速度要比AOF快得多

rdb缺点：
在一定的间隔做一次备份，容易丢失最近一次快照期间的数据
内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork，在更大的数据集中，可能会导致服务请求的瞬间延迟。fork的时候内存中的数据贝克隆了一份，大致2倍的膨胀性，需要考虑

触发rdb快照的场景：
配置文件中默认的快照配置
手动save/bgsave命令
执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
执行shutdown且没有设置开启AOF持久化
主从复制时，主节点自动触发

如何禁用rdb快照：动态所有停止RDB 保存规则的方法：redis-cli config set save ""

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

默认情况下，redis是没有开启AOF的，开启AOF功能需要设置配置：appendonly yes

aof保存的是appendonly.aof文件

aof的写回策略:
Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓存区内容写回磁盘

aof优点：更好的保护数据不丢失、性能高、可做紧急恢复
aof缺点：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

aof重写机制：当AOF文件的大小超过所设定的峰值时，redis就会自动启动AOF文件的内容压缩，只保留可恢复数据的最小指令集；可以手动使用命令bgrewriteaof来重写

在同时开启rdb和aof持久化时，重启时只会加载aof文件，不会加载rdb文件

RDB+AOF混合模式（推荐）
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据
RDB镜像做全量持久化，AOF做增量持久化
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分时AOF格式。