关于redis的一些细节

(这位大佬写的十分详细,借鉴一下https://mp.weixin.qq.com/s/m7WEAC6juUYnA5yyKgR4uA)

一、redis的持久化

redis持久化机制有两种:RDB(快照)(Redis Database)、AOF日志(Append Only File)

1、快照(RDB):快照是内存数据的二进制序列化形式,在存储上非常紧凑

在redis中,生成RDB的方式有两种,一种使用save,另一种使用bgsave,但是底层实现,都是调用的同一个函数——rdbsave,只是调用方式不同

(1)save方法:直接调用rdbsave方法,此时会阻塞Redis主进程,直至快照文件的生成。

(2)bgsave方法:此方法会调用glibc函数fork一个子进程,快照持久化完全交给子进程处理,子进程调用rdbsave方法,父进程继续处理客户端请求。如果内存资源不足,fork失败返回0;fork成功后,父进程处理客户端请求,子进程处理快照写磁盘,他们共享内存的代码段和数据段,节约内存资源(进程分离的一瞬间,内存增长无明显变化)

问题:子进程做数据持久化,不会修改内存数据结构,其只对数据结构进行遍历读取,然后序列化到磁盘上。而在此时,父进程在服务客户端的请求时,对内存数据结构进行修改了,这种情况是怎么处理的?

答:操作系统的COW机制(Copy On Write)(写时复制技术)。出现这种情况,会使用COW机制进行数据段页面分离。数据段由很多操作系统的页面组合而成,当父进程对一个页面数据进行修改时,会将被共享的页面复制一份分离出来,然后对这个复制的页面进行修改,而此时子进程相应的页面没有变化,它看到的内存里的数据在进程产生的那一瞬间就凝固了,称之为 “快照” 。

问题:父进程持续的修改操作,会造成越来越多共享的页面被复制出来,内存持续增长怎么办?

答:内存确实会持续增长,但是不会超过原有数据内存的2倍大小。同时,redis里面的冷数据占比较高,很少出现所有页面都被分离的情况,被分离的页面只占其中一部分。

问题:在调用了bgsave方法后,有没有可能又调用了save方法?

答:在调用bgsave、或者save方法时,会提前判断bgsave方法是否在执行,若bgsave在执行,就不会再执行save或者bgsave命令。

问题:生成了rdb文件后怎么使用呢?

答:Redis在启动服务器的时候会调用rdbload函数,会把生成的RDB文件给加载到内存中来,在载入的期间,每载入1000个键就会处理一次已经到达的请求,但是只会处理publish、subscribe、psubscribe、unsubscribe、punsubscribe这个五个命令。其余的请求一律返回错误,直到载入完成。

快照的优缺点:直接搬运一下

 

2、AOF

由于RDB可能会造成数据丢失,redis提供了另外一种持久化机制。

AOF日志存储的是Redis服务器的顺序指令序列,AOF日志只记录对内存进行修改的指令记录!(与快照不同)

Redis在接收到客户端修改指令后,进行参数校验、逻辑处理,如果没问题,就立即将该指令文本存储到AOF日志中,也就是说,先执行指令才将日志存盘!

1、AOF记录过程:当客户端发送指令到Redis服务器后,只要命令成功执行,这个命令先写入aof_buf,Redis的AOF写入缓冲区(不会立即写入磁盘,因为频繁的IO操作,会大大降低性能),每隔100ms,会执行serverCron函数,同时会调用flushAppendOnlyFile函数。这个命令会调用 write将写入缓冲区的数据写入到AOF文件中,但是这个时候还是没有真正的落到磁盘上。这是OS为了提高写入文件的效率,会将数据暂时写入到OS的内存的缓冲区内,等到缓冲区被填满了或超过了指定的时间,才会调用fsync或者sdatasync真正的将缓冲区的内容写入到磁盘中。但是如果在这期间机器宕了,那么数据仍然会丢失。所以如果想要真正的将AOF文件保存在磁盘上,必须要调用上面提到的两个函数才行。

原文地址:https://www.cnblogs.com/aoligei/p/15129465.html