复述,提供了两种持久化方式,一种是基于快照形式的RDB,另一种是基于日志形式的AOF,每种方式都有自己的优缺点,本文将介绍复述这两种持久化方式,希望阅读本文后你对复述的这两种持久化方式有更加全面,清晰的认识。
RDB快照方式持久化
先从RDB快照方式聊起,RDB是复述,默认开启的持久化方式,并不需要我们单独开启,先来看看跟RDB相关的配置信息:
<代码> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #快照# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #保存DB alt="一文带你深入了解复述的持久化方式及其原理">bgsave命令大概有以下几个步骤:
-
<李> 1,执行bgsave命令,复述,主进程判断当前是否存在正在执行的RDB/AOF子进程,如果存在,bgsave命令直接返回不在往下执行。
<李> 2,父进程执行叉操作创建子进程,叉操作过程中父进程会阻塞,叉完成后父进程将不在阻塞可以接受其他命令。
<李> 3,子进程创建新的RDB文件,基于父进程当前内存数据生成临时快照文件,完成后用新的RDB文件替换原有的RDB文件,并且给父进程发送RDB快照生成完毕通知李
上面就是bgsave命令背后的一些内容,RDB的内容就差不多了,我们一起来总结RDB持久化的优缺点,<强> RDB方式的优点:
-
<李> RDB快照是某一时刻复述,节点内存数据,非常适合做备份,上传到远程服务器或者文件系统中,用于容灾备份李
<李>数据恢复时RDB要远远快于AOF李
有优点同样存在缺点,<强> RDB的缺点有:
-
<李> RDB持久化方式数据没办法做到实时持久化/秒级持久化。我们已经知道了bgsave命令每次运行都要执行叉操作创建子进程,属于重量级操作,频繁执行成本过高。
<李> RDB文件使用特定二进制格式保存,复述,版本演进过程中有多个格式的RDB版本,存在老版本复述,服务无法兼容新版RDB格式的问题
如果我们对数据要求比较高,每一秒的数据都不能丢,RDB持久化方式肯定是不能够满足要求的,那复述,有没有办法满足呢,答案是有的,那就是接下来的AOF持久化方式
AOF文件持久化方式
复述,默认并没有开启AOF持久化方式,需要我们自行开启,在复述。参看配置文件中将<代码> appendonly没有> appendonly是的> appendonly.aof
<代码> * 2 6美元 选择 1美元 0 * 3 3美元 集 6美元 mykey1 6美元 你好 * 3 3美元 集 4美元 key2 5美元 你好 * 18美元
大概就是长这样的,具体的你可以查看你复述,服务器上的<代码> appendonly。aof> appendonly。aof 文件中国修改值,等复述,重启时将会加载修改之后的值。看似一些简单的操作命令,其实从命令到<代码> appendonly。aof 这个过程中非常有学问的,下面时aof持久化流程图:
在AOF持久化过程中有两个非常重要的操作:<强>一个是将操作命令追加到AOF_BUF缓存区,另一个是AOF_BUF缓存区数据同步到AOF文件强,接下来我们详细聊一聊这两个操作:
<强> 1,为什么要将命令写入到aof_buf缓存区而不是直接写入到aof文件?
我们知道复述是单线程响应,如果每次写入AOF命令都直接追加到磁盘上的AOF文件中,这样频繁的IO开销,复述的性能就完成取决于你的机器硬件了,为了提升复述的响应效率就添加了一层aof_buf缓存层,利用的是操作系统的缓存技术,这样就提升了复述的性能,虽然这样性能是解决了,但是同时也引入了一个问题,aof_buf缓存区数据如何同步到AOF文件呢?由谁同步呢?这就是我们接下来要聊的一个操作:<强> fsync操作
<强> 2,aof_buf缓存区数据如何同步到aof文件中?
aof_buf缓存区数据写入到aof文件是有linux系统去完成的,由于linux系统调度机制周期比较长,如果系统故障宕机了,意味着一个周期内的数据将全部丢失,这不是我们想要的,所以linux提供了一个fsync命令,fsync是针对单个文件操作(比如这里的aof文件),做强制硬盘同步,fsync将阻塞直到写入硬盘完成后返回,保证了数据持久化,正是由于有这个命令,所以复述,提供了配置项让我们自行决定何时进行磁盘同步,复述,在复述。会议中提供了
