redis：RDB和AOF机制
https://i-blog.csdnimg.cn/blog_migrate/30de044c26404442622bf8753ea88a2e.jpeg#pic_center个人主页 ： 个人主页
个人专栏 ： 《数据结构》 《C语言》《C++》《Linux》《网络》 《redis学习条记》
前言
redis是一个内存数据库，把数据存储在内存中的，而内存中的数据是不持久的，要想能够做到持久，就需要让redis把数据存储到硬盘上。但redis相比于mysql如许的关系型数据库，最明显的特点就是效率高，速度快。如许便导致redis为了包管速度快，数据要存储在内存中，又为了持久化，数据要存储到硬盘中；
当要插入一个新的数据时，需要把这个数据，“同时”写入到内存和硬盘；当要查询某个数据时，直接从内存读取；硬盘数据只是在redis重启的时候，用来恢复内存中的数据的。
redis支持RDB(Redis DataBase)和AOF(Append Only File)两种持久化机制
RDB
RDB定期的把redis内存中的所有数据，都给写入硬盘中，生成一个快照；之后redis一旦重启，就可以根据刚才的快照，把内存中的数据恢复返来。
定期具体而言，又两种方式：手动触发，自动触发
[*]手动触发
save命令，阻塞当前redis服务器，直到RDB过程完成为止。会导致类似于 keys *的后果，一般不建议使用save
bgsave命令，redis历程执行 fork 操纵创建子历程，RDB持久化过程由子历程负责，完成后自动竣事；阻塞只发生在fork阶段
redis内部所有涉及到RDB的操纵都接纳类似bgsave的方式
2.自动触发
在redis设置文件中(linux中，redis的默认设置文件路径是/etc/redis/redis.conf)，设置下，使redis每隔多长时间和每产生多少次修改就触发
https://i-blog.csdnimg.cn/direct/fb144d65c25e4008a06bc312c7b8cf24.png
使用save设置，如"save m n"表示 m秒内数据集发送了 n 次修改，自动RDB持久化；
通过shutdown 命令，关闭redis服务器，也会触发 service redis-server restart ，正常关闭
redis 举行主从复制的时候，主节点也会自动生成RDB快照，然后把RDB快照文件内容传输给从节点
bgsave命令的运行流程
https://i-blog.csdnimg.cn/direct/1a7dd1830d8d4d1fb6de53b221c78a6b.png
[*]执行bgsave命令，redis父历程判断当前历程是否存在其它正在执行的子历程，如RDB/AOF子历程，如果存在bgsave命令直接返回
[*]父历程fork完成后，bgsave命令会返回"Background saving started" 信息并不再阻塞父历程，父历程可以继续相应其它命令
[*]子历程创建RDB文件，根据父历程内存生成临时快照文件，完成后对原有文件举行原子更换
[*]子历程发送信号给父历程表示完成，父历程更新统计信息
redis生成的rdb文件，存放在redis的工作目录中的，可以在redis设置文件中，举行设置
https://i-blog.csdnimg.cn/direct/944de23c723e4fbfbea28149daab9eb7.png
https://i-blog.csdnimg.cn/direct/56fa024487924be386572a33abe1faa5.png
dump.rdb就是rdb机制生成的镜像文件，redis服务器默认的就是开启rdb的；dump.rdb文件就是二进制文件，把内存中的数据，以压缩的形式(默认接纳LZF算法)，生存到这个二进制文件中。
后续redis服务器重新启动，就会尝试加载这个rdb文件，如果发现格式错误，大概会加载数据失败
https://i-blog.csdnimg.cn/direct/211e1d5928604d588dd9f90cca1750a0.png
redis-check-rdb是redis提供的rdb文件查抄工具
[*]RDB是一个紧凑压缩的二进制文件，代表redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6个小时执行bgsave备份，并把RDB文件复制到远端呆板或者文件体系中用于灾备
[*]redis加载RDB恢复数据远远快于AOF的方式；RDB使用二进制的方式组织数据，直接把数据读取到内存中，按照字节的格式取出来放到结构体/对象中即可，但AOF是使用文本的方式来组织数据，则需要举行一系列的字符串切分
[*]RDB方式数据每办法走到实时持久化/秒级持久化，bgsave每次运行都需要执行fork创建子历程，属于重量级操纵，频繁执行本钱过高
[*]RDB文件使用特定二进制格式生存，redis版本演进过程有多个RDB版本，兼容大概有风险；可以通过写一个程序，直接遍历旧的redis中的所有key，把数据取出来插入到新的redis服务器中
AOF
redis的AOF(Append Only File)机制是一种持久化机制，用于将redis服务器接收到的所有写操纵命令以追加的方式写入到磁盘中的日记文件中，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的重要作用是办理数据持久化的实时性
开启AOF功能需要设置设置：appendonly yes，AOF文件名通过appendfilename设置，地点目录和RDB一样(/var/lib/redis)
https://i-blog.csdnimg.cn/direct/22e334330f364f328ed69b473524ba32.png
https://i-blog.csdnimg.cn/direct/ed3f50bfbd4e4fa8b6a06fb9c86a0590.png
https://i-blog.csdnimg.cn/direct/61518eaf7d014f32af86a8ac9cf3f183.png
所有的写入命令会追加到aof_buf(缓冲区)中，AOF缓冲区根据对应的策略向硬盘做同步操纵，随着AOF文件越来越大，需要定期对AOF文件举行重写，达到压缩目的，当redis服务器启动时，可以加载AOF文件举行数据恢复
redis执行命令速度快的重要缘故起因，是直接操纵内存；现在引入AOF后，又要写内存，又要写硬盘还可以想之前一样快吗？实际上，并没有影响到redis处理请求的速度，有以下两个缘故起因：
[*]AOF机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区，先积累一部分，再同一写入硬盘；如许大大降低了写硬盘的次数
[*]硬盘上读写数据，顺序读写的速度是比较快的(比内存还是慢许多)，AOF是每次把新的操纵写入到原有文件的末尾，属于顺序写入
但缓冲区的数据还是在内存中，如果redis服务器突然挂了，缓冲区的数据就丢了。
redis给出一些选项，让我们选择缓冲区的刷新策略
https://i-blog.csdnimg.cn/direct/e00157cf61154d0ea6826b69f20aed9b.png
刷新频率越高，性能影响就越大，数据可靠性就越高
刷新评率越低，性能影响就越小，数据可靠性就越低
体系调用write 和 fsync说明：
[*]write操纵会触发延迟写(delayed write)机制，linux在内核提供页缓冲区用来提高硬盘IO性能，write操纵在写入体系缓冲区后立即返回，同步硬盘操纵依靠于体系调度机制；如：缓冲区页空间写满或到达特定时间周期。同步文件之前，如果此时体系故障宕机，缓冲区内数据丢失
[*]fsync针对单个文件操纵，做强制硬盘同步，fsync将阻塞直到数据写入到硬盘
[*]设置为always时，每次写入都要同步AOF文件，性能很差，在一般的SATA硬盘上，只能支持大约几百TPS写入。
[*]设置为no时，由于操纵体系同步策略不可控，固然提供了性能，但数据丢失风险大大提高
[*]设置everysec，是默认设置，兼顾数据安全和性能。理论上最多丢失1秒的数据
https://i-blog.csdnimg.cn/direct/099bb620040046aeb554865751948a1d.png
AOF文件持续增长，体积越来越大，会影响到redis下次启动的启动时间；redis启动的时候要读取aof文件内容(记载中间过程)，而这个AOF文件有一些内容是多余的。
https://i-blog.csdnimg.cn/direct/0fff68cc0a484f5b954a11037d9d773a.png
类似上述操纵，实际上AOF只需要记载 set key 5即可。
因此redis就存在一个机制，能够针对AOF文件举行整理操纵；也就是能够删除多余的内容，使AOF文件巨细变小
AOF重写过程可以分为手动触发和自动触发
手动触发：调用bgrewriteaof命令
自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时间
[*]auto-aof-rewrite-min-size：触发重写时AOF的最小文件巨细
[*]auto-aof-rewrite-percentage：当前AOF占用巨细相比上次重传写时增加的比例
https://i-blog.csdnimg.cn/direct/e90e15e27156417da4e4d3d34d678d11.png
https://i-blog.csdnimg.cn/direct/5017720de7f54550b86b87ea52e4ed9d.png
执行AOF重新请求，如果当前历程正在执行AOF重写，请求不执行；如果当前历程正在执行bgsave操纵，重新命令延迟到bgsave完成之后再执行
父历程执行fork创建子历程；
父历程继续相应其它命令，所有写入命令仍然写入AOF缓冲区并根据appendfsync策略同步到硬盘，包管旧AOF文件机制正确(重写过程中，如果redis服务器挂了，可以根据旧AOF文件恢复数据)；子历程根据内存快照，将命令合并到新的AOF文件中；
子历程完成重写，新AOF文件写入后，子历程发送信号给父历程，父历程把AOF重写缓冲区内临时生存的命令追加到新的AOF文件中，用新AOF文件更换旧AOF文件
注意：
重写的时候，不关心AOF文件中原来都有什么，只关心内存中最终的数据状态，子历程只需要把内存中当前的数据，获取出来，以AOF格式写入到一个新的AOF文件中；内存中的数据状态，就已经相当于把旧AOF文件结果整理后的样子;
RDB对于fork之后的新数据，就直接置之不理；AOF则对于fork之后的新数据，接纳aof_rewrite_buf缓冲区的方式来处理；这是由于RDB本身的计划理念就是用来“定期备份”的，AOF的计划理念是“实时备份”
AOF本来是按照文本的方式写入文件的，但文本的方式写入文件，后续加载本钱比较高；redis就引入了“混合持久化”的方式，结合了RDB和AOF的特点
按照AOF的方式，把每一个请求/操纵，都记载文件，在触发AOF重写之后，把当前内存的状态按照RDB的二进制格式写入到新的AOF文件中，后续再举行的操纵，仍然按照AOF文本的方式追加到文件后面
https://i-blog.csdnimg.cn/direct/2eaf174231524cc1ac2a1ef588327184.png
该选项为 yes 表示开启混合持久化
当redis上同时存在AOF文件和RDB快照时，启动redis以谁为主？以AOF为主，RDB直接被忽略了，AOF中包罗的数据比RDB更全。
https://i-blog.csdnimg.cn/direct/b011673b8e504b60aae72391e7875c30.png
总结
以上就是我的redis学习条记
https://i-blog.csdnimg.cn/blog_migrate/5b229573a341cf2cca7470f4188c9fb0.gif#pic_center
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]