RDB
rdb持久化原理：
会涉及到操作系统底层的fork调用，详情查看：https://zhangxueliang.blog.csdn.net/article/details/104076571
会fork出一个子进程用于持久化。
当redis主进程发生数据修改的时候，会触发内核级别的写时复制操作，写数据到持久化文件是子进程来完成的，数据的增删改是在父进程中进行的，所以redis的持久化是fork+copy on write来实现的。
比如8点fork出一个子进程用于持久化操作，此时子进程拷贝的是8点时的数据，父子进程的数据修改，彼此都不可见。假如10点redis数据发生了修改，此时会由内核的写时复制机制触发数据复制操作，将引用指向新的数据，此时子进程的引用还是指向旧数据。写时复制不是为了数据同步，而是数据隔离。
fork出来的子进程会一直等到数据持久化做完后才销毁。每次持久化开始时都会fork出一个子进程。每次拍快照（持久化）都是当前时间点的全量数据覆盖之前的快照数据，如果快照采用增量更新的方式的话，需要在内存中判断哪些数据有更新哪些没更新，反而消耗CPU资源。
拷贝引用的成本比拷贝数据的成本低很多，因为一个引用的大小是4个字节，但引用指向的数据可能是一个数组几百个字节。
redis RDB持久化配置方式：
如果想关闭持久化，只需在配置文件redis.conf中配置：
save ""redis.conf配置文件中配置持久化文件相关信息：
RDB的弊端：
①不支持拉链。由于只有一个dump.rdb持久化文件，所以会丢失前些天的数据，需要手工将dump文件拷贝出来。比如：我需要某一天的dump文件，如果不手工干涉的话，也许已经被覆盖了。
②丢失数据相对多一些。时点与时点之间的窗口数据容易丢失，比如8点得到一个dump.rdb，8：15要落一个rdb，结果挂机了。
RDB的优势：
类似于Java中的序列化，恢复数据的速度较快。想象一下，传输一个json数据然后解析成对象load到内存快还是直接传输一个二进制字节数组直接就怼到了内存快？用大腿想都知道是后者啦！
正是由于RDB的弊端，才有了AOF：Append Only File 的持久化机制。
AOF
将redis的写操作记录到文件中。类似于MySQL中的redo log和binlog一样。这样的话，丢失数据就会少啦。
在redis中，RDB和AOF可以同时开启，但是AOF优先，只会使用AOF做重启后的数据恢复。
aof执行日志文件中的命令，速度相对rdb要慢。但丢失数据相对rdb少。
aof天然的弊端：
①日志体量无限变大；
②恢复慢。
优点如果能保住，日志还是可以用的，需要设计一个方案让日志，AOF足够小。
4.0以前通过日志重写来实现：
①删除抵销的命令
②合并重复的命令
4.0以后也是通过日志重写来实现，只不过进行了优化：
①将老的数据RDB到aof文件中，存储的是二进制格式的日志数据。
②将增量的以redis指令的方式append到aof日志文件中。
AOF是一个混合体，利用了RDB的快和日志的全量。
redis 4.0 以后，AOF中包含RDB全量快照数据，增加记录新的写操作。
开启AOF
IO流中为什么要flush一下才能将数据写到磁盘，因为磁盘IO操作都是由操作系统内核来进行的，数据先是下入到内存的buffer中，flush就是将数据从buffer中刷到硬盘。redis中也是如此：
always：每次发生数据变更，立即持久化到硬盘
ererysec：每秒持久化一次，也就是每秒调一次flush将buffer数据刷到硬盘
no：等待OS自己将数据刷到硬盘，buffer一满OS就会刷到硬盘。
效率对比：always < everysec < no
no-appendfsync-on-rewrite默认是no：可能会发生丢数据的情况。但不会与自己的子进程争抢IO操作权。
标签：AOF,持久,redis,RDB,原理,日志,数据 来源： https://blog.51cto.com/u_7692005/3000289
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。