小编给大家分享一下复述中RDB和AOP持久化是什么,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获、下面让我们一起去了解一下吧!
复述是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失。幸好复述,还为我们提供了持久化的机制,分别是RDB(复述,数据库)和AOF(添加alt="复述中RDB和AOP持久化是什么">
执行完成时候如果存在老的RDB文件,就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万,这种方式显然不可取。
<强> 2,bgsave触发方式
执行该命令时,复述,会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体流程如下:
具体操作是复述,进程执行叉操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在叉阶段,一般时间很短。基本上复述,内部所有的RDB操作都是采用bgsave命令。
<强> 3,自动触发
自动触发是由我们的配置文件来完成的,在复述。参看配置文件中,里面有如下配置,我们可以去设置:
①保存:这里是用来配置触发复述的RDB持久化条件,也就是什么时候将内存中的数据保存到硬盘,比如“拯救m n”。表示米秒内数据集存在n次修改时,自动触发bgsave。
默认如下配置:
#表示900秒内如果至少有1个键的值变化,则保存节省900 1 #表示300秒内如果至少有10个关键的值变化,则保存保存300 10 #表示60秒内如果至少有10000个键的值变化,则保存保存60 10000
不需要持久化,那么你可以注释掉所有的保存行来停用保存功能。
②stop-writes-on-bgsave-error:默认值为是的。当启用了RDB且最后一次后台保存数据失败,复述是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上,否则没有人会注意到灾难(灾难)发生了。如果复述,重启了,那么又可以重新开始接收数据了
③rdbcompression;默认值是是的。对于存储到磁盘中的快照,可以设置是否进行压缩存储。
④rdbchecksum:默认值是是的。在存储快照后,我们还可以让复述,使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。
⑤dbfilename:设置快照的文件名,默认是转储。rdb
⑥dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。
我们可以修改这些配置来实现我们想要的效果。因为第三种方式是配置的，所以我们对前两种进行一个对比：
4、RDB 的优势和劣势
①、优势
（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
②、劣势
RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
三、AOF机制
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
1、持久化原理
他的原理看下面这张图：
每当有一个写命令过来时，就直接保存在我们的AOF文件中。
2、文件重写原理
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。
