Redis持久化之RDB与AOF

面试的时候被问了几次关于Redis的持久化问题，但是只是泛泛的了解，今天深入琢磨一番。

首先为什么要有持久化,持久化用来解决什么问题，怎么解决？
我们都知道Redis是内存数据库，在运行时所有的数据都存放在内存中，可是如果突然死机，或者数据库崩溃，或者仅仅是简单的重启，我们内存中的数据就丢失，那就没人来使用Redis了。正是因为以上的这些原因Redis提供了持久化的策略，所谓持久化，就是将Redis内存中的数据库状态保存到磁盘中，避免数据丢失。Redis有两种持久化的策略，一种是基于快照的RDB持久化，一种是基于操作的AOF持久化。

RDB持久化：
RDB持久化既可以手动设置也可以根据服务器配置选项定期执行，该功能可以将某一个时间点的数据库状态保存到一个二进制压缩的RDB文件中，当启动数据库的时候再从RDB文件中读取来恢复数据库状态。

SAVE指令与BGSAVE指令
上面的两个指令时Redis用来手动实现持久化的命令，但是两个命令是有很大区别的。
1. SAVE指令，在使用的时候要阻塞服务器的进程，知道RDB文件生成完毕，服务器才能执行客户端发出的请求，在这之前是要一直阻塞的。
2. BGSAVE指令，使用该指令的时候不会阻塞服务器的进程，而是开启一个子进程来进行RDB文件的生成，而主进程可以继续执行。但是在BGSAVE执行的时候，服务器会拒绝SAVE指令（两个磁盘写入操作同时进行，怎么想都不是好主意吧，嘻嘻）
3. 因为AOF更新的频率比较高，如果服务器开启了AOF持久化，那么服务器会优先使用AOF文件来还原数据库，当AOP关闭的时候，服务器在启动的时候会寻找RDB文件来恢复数据库。

自动间隔保存
可以在服务器中配置，让数据进行自动保存的策略
save 900 1
save 300 10
save 60 10000
而实现自动保存功能主要依赖服务器状态中的dirty属性和lastsave属性：
dirty属性是距离上一次成功执行save或者bgsave之后，服务器对数据库进行了，多少次修改。
lastsave属性上一次成功执行save或者bgsave的时间。
而服务器正是依赖这两个属性来按照设置的自动保存间隔生成RDB文件的。

AOF持久化
AOF使用过保存所有对数据库的写命令来做持久化的，这是与RDB不同的，并且AOF是细粒度的。
AOF中所有的写命令都是以Redis命令请求协议的格式保存，命令会先保存在缓冲区中然后定期的写到RDB文件中。服务器只要载入并重新执行AOF文件中的操作就可以恢复数据库。
AOF重写可以产生一个新的AOF文件，这个文件比原有的文件更小，该功能是通过读取数据库中的键值对来完成的，目的是消除冗余的记录，比如说AOF文件中记录的十次链表的插入操作，而这十次操作每个都单独占据一行，而这可以通过一个命令 链表插入多个值的命令来实现，这样就极大的消除了冗余，而重写是一个容易引起歧义的名字，实际上生成新的AOF文件并不对原有的AOF文件尽行任何操作。
在执行BGREWRITEAOF操作的时候，Redis服务器会维持一个AOF重写缓冲区，在子进程进行AOF重写的时候，缓冲区会记录在这期间所有对于Redis的写操作。当重写完成后将缓冲区中的内容追加到新的AOF文件的末尾。

RDB的优点：
RDB是一个非常紧凑的文件，保存了某个时间点的数据库数据集。它很适合用于备份和灾难恢复。RDB可以最大化Redis的性能。父进程可以调用子进程进行RDB文件的生成，而父进程不阻塞。RDB在恢复大数据集的时候速度要比AOF快。

RDB的缺点：
如果要尽量防止数据的丢失，那么RDB就不合适了，因为RDB需要保存整个数据库中的快照，如此大的IO操作可能好几分钟进行一次，一旦服务器崩溃，那么可能就会丢失好几分钟的数据，而AOF虽然进行重写，但是无论重写的时间有多长，都不会损失数据库的耐久性。

AOF的优点：
实时性比较高，即使发生了数据库的崩溃也就是损失了极少量的数据而已，可以通过合理的设置fsync时间来保证AOF存储数据的安全性，fsync默认为一秒，就算服务器宕机也不过是损失一秒的数据。Redis可以在AOF文件过大的时候进行AOF重写，保证AOF文件中是当前数据集所需要的最小命令的集合，而这个重写的过程是绝对安全的。

AOF的缺点：
AOF的体积过大，在进行大量数据载入时性能不如RDB。根据所使用的fsync策略，AOF的策略可能会略低于RDB。