Redis(一)——持久化
Redis大家都在经常使用，其功能非常强大，利用其内存存储、存取快的特新能够帮助我们解决很多难题。在项目中，我们可利用Redis：1作为缓存；2作为消息队列；3生成业务唯一键；4分布式锁控制；5内存数据库……可以很好的解决一些高并发、高性能要求的业务场景。
针对Redis的安装，五种数据结构（字符串string、哈希hash、列表list、集合set、有序集合zset）,对慢查询、shell、pipeline、事务、lua等小功能的支持，这里都不再进行赘述，可以查看redis文档进行了解：http://www.redis.cn/documentation.html
今天我们来细看一下Redis的持久化。
作为内存数据库，Redis也支持数据的持久化功能（防止由于各种意外情况，导致内存数据完全消失，可以在持久化文件中进行恢复，将损失恢复到最小），包括RDB(Redis DataBase)和AOF（Appen Only File）两种方式。
一，RDB：此种方式是将当前进程数据生成快照保存到硬盘的过程。我们一下几个方面看下：
1，触发机制：
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，不建议线上使用。
bgsave命令：Redis进程执行fork操作创建子进程，RDB过程由于子进程负责完成，完成后自动结束，阻塞只在fork阶段，已经完全替代save命令。
我们可以手动触发，也可以自动触发：1，save m n 表示m秒数据集存在n次修改时，自动触发bgsave操作；2，从节点执行全量复制操作，主节点会自动bgsave生成RDB文件并发送给从节点；3，执行debug reload命令重新加载Redis时；4，默认执行shutdown时，如果没有开启AOF会自动bgsave.
2，执行流程：
redis将RDB文件保存在dir配置的指定目录下，文件通过dbfilename进行配置。默认采用LZF算法对生成的RDB文件进行压缩处理，可以通过config set rdbcompresssion{yes|no}动态修改。
二，AOF:以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。解决了持久化的实时性。
1，流程机制：
说明：1，所有的写入命令会追加到aof_buf(缓冲区)中；2，AOF缓冲区根据对应的策略向硬盘做同步操作；3，AOF文件越来越大，需要对其进行重写，达到压缩的目的；4，Redis服务器重启时，可以加载AOF文件进行数据恢复。
这里重点说下重写机制rewrite，重写后的AOF文件为什么会变小呢？1，进程内已经超时的数据不再进行写入文件；2，旧的AOF文件含有无效的命令，例如del key1，set a 111，set a 222，重写能够使进程内数据直接生成，也就是最终结果，不在进行过程的一步一步记录。3，多条写命令可以合并一个，例如：lpush list a、lpush list b、lpush list c可以转化为lpush a b c …… 从而达到减小控件的效果，当然在Redis进行加载的时候也会变得更快。
3，比较一下二者的优缺点吧：
| 方式 | 优点 | 缺点 |
| RDB | 1.RDB是一个非常紧凑的二进制文件，他保存了某个时间点的数据集，非常适用于数据集备份。例如：每6小时执行bgsave备份，并把文件copy到远程机器或者文件系统中，用于灾难恢复。 2.与AOF相比，在恢复大的数据集时，RDB方式会更快一些。 |
1.RDB方式数据没办法做到实时持久化、秒级持久化。bgsave属于重量级操作，频繁执行成本过高。 2.RDB文件使用特定的二进制格式保存，老版本无法兼容新版本。 |
| AOF | 1.AOF能够做到实时持久化、秒级持久化。使用不同的faync策略（无fsync，每秒fsync-默认，每次写的时候fsync），Redis性能依旧很好，一旦出现故障，最多丢失1秒的数据。 2.AOF文件是一个只追加的日志文件，轻量级。 3.AOF的重写功能，更够及时的减小空间占用。 4.AOF文件有序的保存了对数据库执行的所有写入操作，为Redis协议的格式保存，非常易读，分析也非常轻松。 |
1.对于相同的数据集，AOF文件的体积通常大于RDB文件体积； 2.根据所使用的fsync策略，AOF的速度可能会慢于RDB。 |
综上，Redis的持久化，两种方式是互补的，我们可以用AOF进行实时备份，而利用RDB进行一定时间内的全量备份。当然更要根据我们的实际业务要求，做出合理的选择，以不变应万变。