Redis之Redis持久化

Redis（Remote Dictionary Server）是一个可持久化的内存、Key-Value数据库。

作为内存数据库，为了防止因服务器断电或系统宕机而引起的数据丢失问题，Redis自带了持久化功能，就是将内存中的数据同步到磁盘来保证持久化（防止数据丢失）。

Redis支持两种持久化方式：RDB（redis database）和AOF（append only file）。

•  RDB（redis database）持久化

概念：在指定的时间间隔内将内存中的数据集快照（Snapshot）写入磁盘，待服务重启时，将快照文件读入内存中。

原理：在执行持久化时，redis使用Fork的方式单独创建一个进程来进程持久化，该进程会先将内存中的数据写入到一个临时文件中，待持久化结束时，用此临时文件替换掉上次持久化保存的文件（默认的文件名为dump.rdb）。

Fork原理：复制一个与当前进程一样的进程，新进程的所有数据都与原进程一样，但是一个全新的进程，并作为原进程的子进程。

触发条件： 可以通过 redis命令 或者配置 redis.conf 文件来指定redis持久化的时机。

（1）使用命令

　　save ( 立刻redis数据持久化，其他全部阻塞 )

　　bgsave ( redis会在后台异步进行快照操作，同时还可响应客户端的请求，可用命令 lastsave  获取最后一次成功执行快照的时间 )

　　flushall  ( 清空命令也会触发持久化操作，但dump.rdb文件中是空的，无意义)

　　shutdown  ( 关闭数据库命令也会触发redis持久化操作 )

（2）使用 redis.conf 配置文件

　　相关配置位于 redis.conf 文件中的 "SNAPSHOTTING" 配置部分：save <seconds> <changes> 指定在 seconds 秒内有 changes 次跟新操作，就进行一次持久化。

　　

禁用RDB持久化： 可以通过 redis命令 或者配置 redis.conf 文件来禁用 RDB持久化　　　　　　

（1）使用命令

　　redis-cli config set save ""

（2）使用 redis.conf 配置文件

　　相关配置位于 redis.conf 文件中的 "SNAPSHOTTING" 配置部分，设置 save "" 配置时，代表禁用RDB持久化。

　　　　　　　　　　　　

持久化文件：位于 redis.conf 文件中的 "SNAPSHOTTING" 配置部分：

　　dir  参数配置持久化文件的目录，dbfilename 参数配置持久化参数的名称。

恢复持久化文件：将备份文件移动至  dir  参数配置持久化文件的目录下，并将文件名改为 dbfilename 参数配置持久化参数的文件名，然后启动数据库即可恢复数据。

　　若 dump.rdb 文件存在异常，数据恢复将报错。可使用命令 redis-check-dump --fix <filename> 命令对 dump.rdb 持久化文件进行修复，然后重启redis服务即可。

优点：持久化过程中，主进程不进行任何IO操作，对于大规模的数据恢复，具有极高的性能。

缺点：RDB最后一次持久化后的数据可能会因为redis意外down掉而丢失最后一次快照后修改的所有数据；
　　Fork时，内存数据被克隆，大致2倍的膨胀性，会对服务器造成一定的压力，影响性能。　　　

应用：适合大规模数据恢复，且对恢复数据的完整性、一致性不是很严格，这种情况下RDB比AOF更加高效。

• AOF（append only file）持久化 

原理：以日志的形式来记录每个写操作（读操作不记录），只许追加文件，不可改写文件，redis启动时，将根据日志文件内容将写指令从前到后执行一次以完成数据的恢复。

触发条件： 可以通过配置 redis.conf 文件来指定redis持久化的时机。

　　默认AOF持久化时关闭的，将参数值设置为 yes 即开启AOF持久化。

　　appendfsync 参数用于指定同步频率，具体使用如下图。

　　

持久换文件：位于 redis.conf 文件中的 "SNAPSHOTTING" 配置部分：

　　dir  参数同时也配置 AOF持久化文件的目录；

　　appendfilename 参数（上图中）用来指定 AOF持久化文件的文件名。

恢复持久化文件：

　　保证 redis.conf 文件中 dir  参数 指定的目录下存在与 appendfilename 参数配置的文件名相同的.aof文件，重启服务时即可恢复。

　　当同时开启 AOF 和 RDB 两种持久化时，启动服务时，会优加载 AOF 持久化文件进行数据的恢复。　　　　　　　

　　若 AOF文件存在异常，数据恢复将报错。可使用命令 redis-check-aof --fix <filename> 命令对 .aof 持久化文件进行修复，然后重启redis服务即可。

AOF持久化文件Rewrite重写机制：

　　引入重写机制背景：AOF采用文件追加的方式，将导致文件越来越大，故新增重写机制。当AOF文件大小超过所设置的阈值时，Redis将启动AOF内容压缩，只保留可以恢复数据的最小指令集。

　　重写原理：当AOF文件大小持续增长超过配置参数  设置的阈值时，redis将fork出一条新进程来将文件重写（也是先将内容写入临时文件，最后再rename）。重写AOF文件时，并不是参照旧的AOF文件，而是遍历新进程内存中的数据，每条记录都添加一条set语句，从而重写一个新的AOF文件，只保留可以恢复数据的最小指令集，类似于快照。

　　触发机制：可以通过 redis命令 或者配置 redis.conf 文件来配置Rewrite时机

　　（1）使用命令 bgrewriteeaof

　　（2）使用配置文件：redis会记录上一次重写AOF文件的大小。默认配置是当AOF文件大小是上次重写后大小的一倍且文件大于64M触发重写操作。具体配置如下图：

　　优点：可以设置appendfsync 为 每秒同步 每次修改同步 和不同步，最恶劣情况下，丢失不超过两秒的数据

　　缺点：相同数据集的数据，AOF文件远大于RBD文件，且恢复速度慢于RBD；AOF运行效率慢于RBD，每秒同步策略效率较好，不同步效率和RDB相同；AOF在rewrite过程中将新数据写到新文件中造成的阻塞是不可避免的。

• 　RDB和AOF使用指南

　　建议AOF和RDB同时开启；

　　RDB作为后备用途,备份频率设置为 ： save 900 1；

　　减少AOF文件的rewrite频率, 设置重写的基准值： auto-aof-rewrite-min-size 5G auto-aof-rewrite-percentage 100。

　生产使用策略：

　　（1）使用 Master-Slave 主从复制策略；

　　（2）Slaver上使用RDB方式持久化，策略为 save  900 1 ；

　　（3）Master上依据实际情况决定是否使用AOF，如使用，建议重写基础大小设置为5G，重写百分比依据实际确定。