redis的持久化，分为RDB和AOF
RDB 持久化
SAVE和BGSAVE都可用于生成RDB文件，但2个命令区别是：
SAVE 会阻塞redis服务器进程，期间不能处理任何命令请求，知道RDB 文件生成完毕
BGSAVE 会派生出一个子进程，子进程负责创建RDB文件，父进程仍然处理请求。正
tip:因为BGSAVE不会阻塞服务器进程，因此我们在redis里配置RDB的save选项实际上是让服务器每隔多久执行一次BASAVE命令。它的实现逻辑是服务器状态维护了一个dirty计数器和lastsae属性，可以判断多久有多少次修改
save 900 1
save 300 10
save 60 10000
在redis重启时，会自动加载RDB文件。此外，当RDB和AOF同事开启时，由于AOF更新频率高，redis服务器会使用AOF文件还原数据库
-
RDB的优点
1.与AOF相比，RDB在大数据集情况下可以更快地重启，因为这相对于把快照直接导入数据，而不像AOF是一系列的命令重新执行 -
RDB的缺点
1.持久化的频率不如AOF，因此恢复的时候，AOF更为精确
AOF 持久化（Append Only File）
RDB的持久化是通过最终的键值对记录数据库的状态。但AOF类似于mysql的binlog。通过记录服务器执行的写命令来记录数据库状态
在了解过binlog和ES等日志持久化之后，我们都了解到，日志的持久化，也是分阶段的，必然有一个缓冲区，写入，同步的细分步骤。
- 1.缓冲区命令追加：redis服务器在执行写命令之后，会追加写命令到服务器aof_buf缓冲区
- 2.写入和同步，本质上是写入磁盘的2个步骤。写入是将缓冲区的数据写到AOF文件中，但现代的计算机系统调用write系统，会将写入的数据暂时保存在一个内存缓冲区里面，等到填满或者达到指定时限之后，才会真正同步到磁盘。
配置appendfsync
配置文件的appendfsync 选项：1.always，将aof_buff写入所有内容并同步 2.everysec，aof_buff写入，如果同步时间查过1s，那么同步 3.no，将aof_buf写入，何时同步由系统决定。
所有没有真正同步的，都会在宕机的时候丢失，所以always是最安全的，但肯定也是性能最差的，默认为everysec
AOF文件重写 BGREWRITEAOF
AOF随着时间变长，会产生一个新的问题，即AOF文件越来越大。AOF重写会产生一个新的AOF文件，保存的的数据库状态相同，但不会有冗余命令 3.子线程发送完成信号，服务器线程原子性的改名，将AOF新的文件覆盖旧的，完成2个文件的替换
实现原理：1.服务器创建一个新的AOF重写文件 2.去遍历数据库，将最新的键生成AOF命令记录在AOF重写文件里。
为了不堵塞服务器的写入，redis开了子线程进行AOF重写，这会导致子线程缺少一部分服务器线程的最新数据。因此我们会有一个AOF重写缓冲区，redis服务器线程会同时将AOF写入命令发到AOF缓冲区和AOF重写缓冲区
image.png
-
AOF的优点
1.AOF以易于理解和解析的格式一个接一个地包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您使用FLUSHALL命令刷新了所有错误，如果在此期间未执行日志重写，您仍然可以保存数据集，只需停止服务器，删除最新命令，然后重新启动Redis。 -
AOF的缺点
AOF文件通常比同一数据集的等效RDB文件大
官网使用建议
如果您希望一定程度的数据安全性与PostgreSQL可为您提供的数据安全性相当，则应使用两种持久性方法。
如果你非常关心你的数据，但是在发生灾难的情况下仍然会有几分钟的数据丢失，你可以单独使用RDB
网友评论