Redis持久化

前情概要：

　　和一个同事排查一个Redis的问题的时候，同事突然来了句“你知道Redis的几种持久化方式么？”，很自然的就答道“rdb和aof嘛“，同事则说其实有第三种方式“rdb和aof的混合版”，震惊！！！

 

Redis需要持久化的原因：

Redis数据都在内存中，当出现服务挂掉等场景时需要重新启动服务，若未进行持久化则直接数据丢失（其实就和最开始没用文件或者数据库学编程一样吧，重启下代码啥都得从头再来）

 

Redis持久化方式：RDB（快照）、AOF（追加）、混合（持久化操作数据rdb、之后操作aof）

 

RDB（快照）

　　原理：将当前内存中的redis库中的数据写入磁盘（主进程会fork一个子进程执行BGSAVE命令来将内存中redis的数据写入临时持久化文件，同时主进程继续接收请求提供服务，待快照生成后使用临时文件替换原持久化文件）

　　参数设置：配置文件中或者命令行修改参数，save seconds  updateCount（即在指定时间内执行了指定条修改操作将执行一次持久化），可设置多条

　　优点：1、文件紧凑、小   2、性能较优    3、大数据集恢复比aof快  4、适用容灾（文件小传输快、恢复快）

　　缺点：1、故障时会丢失最后一次持久化后的数据   2、大数据集时fork子进程较耗时  3、可读性差

　　持久化命令：bgsave（fork子进程进行持久化）   save（直接阻塞进行持久化）

 

AOF（追加）

　　原理：将所有修改指令追加到文件末尾（恢复时从头一条条执行命令即可）

　　参数设置：appendonly设置为yes，appendfsync设置为everysec（每秒执行一次，默认）、always（每条修改命令都执行）、no（不主动执行，由操作系统决定）

　　优点：1、故障时丢失数据少（取决于参数配置） 2、持久化文件兼容性（不受版本制约）、可读性强（协议较简单，了解规则可直接读懂，在未重写前可恢复至指定位置）

　　缺点：1、持久化文件较大 2、性能可能没rdb快 3、可能重新载入时数据不一致

　　持久化命令：bgrewriteaof

 

混合（RDB+AOF）

　　原理：先将内存数据rdb快照存到aof文件前面，然后再将缓冲区数据通过aof格式存到aof文件末尾，然后替换旧文件

　　参数设置：aof-use-rdb-preamble设置为yes

　　优点：结合rdb和aof的优点，持久化文件小，加载快

　　缺点：持久化文件可读性差、兼容性差（4.0前版本不识别）

　　持久化命令：bgrewriteaof

　　恢复：同aof，恢复aof文件，只是aof文件中可能前一部分为rdb格式

 

后话：各个方案都有自己的优劣，没有那种方案是万能最优解，我们需要根据实际的场景来选择持久化的方式，是啊，除了Redis的持久化我们的生活也如此，不是么？