网络安全最新想搞定Redis-持久化数据安全RDB、AOF(2)，2024年最新为什么网络安全能最好地改变网络安全

一、网安学习成长路线图

网安所有方向的技术点做的整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

二、网安视频合集

观看零基础学习视频，看视频学习是最快捷也是最有效果的方式，跟着视频中老师的思路，从基础到深入，还是很容易入门的。

三、精品网安学习书籍

当我学到一定基础，有自己的理解能力的时候，会去阅读一些前辈整理的书籍或者手写的笔记资料，这些笔记详细记载了他们对一些技术点的理解，这些理解是比较独到，可以学到不一样的思路。

四、网络安全源码合集+工具包

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

五、网络安全面试题

最后就是大家最关心的网络安全面试题板块

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

COW(Copy On Write) 机制属于操作系统处理多进程下的一种机制，Redis在持久化的时候会调用glibc函数fork一个子进程。父子进程会共享内存里面的代码段和数据段。

所以持久化的时候是完全交给子进程，而父进程继续处理客户端请求，所以在持久化的时候操作系统采用COW机制进程数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面进行数据修改的时候，先将被父子线程共享的这一个页面复制并分离出来，然后直接对复制的页面进程修改，而此时子进程对应的页面是没有修改的。

Redis采用该机制的简单流程如下。Lunix在fork之后，操作系统会将父进程的所有内存也权限设置为read-only，然后子进程的地址空间指向父进程。当父进程只读时没有问题，当有写内存时，CPU硬件检测到内存也是read-only，于是会触发页异常中断（page-fault），陷入到操作系统的一个中断例程。中断例程中，操作系统采用cow机制会触发异常的也复制一份，于是父子进程各自持有独立的一份，如果这个时候又大量写入操作，会产生大量的分页错误（页异常中断page-fault），从而触发cow机制。

之所以称之为快照也就是说在子进程创建的那一时刻开始。内存的数据就固定下来了，不会发生变化。

RDB的优缺点

优点：

1. 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，保证了redis的高性能
2. 重启恢复数据的时候。数据量比较大时候，Redis直接解析RDB二进制文件，生成对应的数据存储在内存中，比AOF的启动效率更高

缺点

1. 数据安全性低，因为是间隔一段时间进行持久化，如果在持久化之间发生了故障，会丢失数据，这也就决定了该方式更适合在数据要求不严谨的时候采用
2. 系统性能耗费，根据上文提到的Redis执行cow机制时，可以看到大量的分页错误会耗费不少性能在复制上。

AOF（Append Only File - 仅追加文件）

根据上文，快照在某些情况下不是可行的选择，所以AOF很好的支持了。

AOF 原理

该方式非常简单：也就是修改内存的操作命令都会记录下来，加入AOF日志记录都是Redis实例创建以来的所有修改性指令序列，所以恢复也就是顺序执行所有执行。

Redis使用单线程相应命令，如果每次写AOF文件命令都追加到硬盘，会极大地影响处理性能，所以Redis会先写入到aof缓冲区，根据用户配置的同步硬盘策略写入到aof文件中，这个策略可以通过appendfsync参数配置，

• always：每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响
• no：Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
• everysec：Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。

注意，这也是影响Redis性能的参数之一，建议采用 appendfsync everysec（缺省方式）

AOF重写

所谓重写，Redis在长期运行过程中日志会越来越大，在恢复的时候会非常好使，所以我们的目的就是对日志做瘦身

会从以下几点做瘦身：

1. 无效命令可以删除，比如del key1、hdel key2、srem keys、set a111、set a222等，直接用最终的数据生成命令保存下来就行
2. 多条命令可以删除，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c
3. 等等，就不列举了

Redis使用bgrewriteaof指令做瘦身，主要也是开辟一个子进程对内存遍历转化为一系列指令，并序列化到新的文件中，接下来再将操作期间的增量AOF日志追加到新的日志文件中，最终替换了旧的。

AOF重写机制两种方式触发

1. 手动触发：bgrewriteaof指令
2. 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

• auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。

• auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

auto-aof-rewrite-min-size    100auto-aof-rewrite-percentage  64mb复制代码

如上代表AOF文件的大小小于64mb(默认值)，且当前AOF文件大小比基准大小增长了100%时会触发。

AOF优缺点

优点

数据安全，aof持久化配置appendfsync属性，有always，每执行一次命令操作就记录到aof文件一次

缺点

数据集大的时候，比如RDB启动效率低

混合持久化（Redis 4.0版本）

我们根据上文知道，RDB恢复会存在大量数据，AOF恢复性能又较慢，所以在Redis4.0中，采用混合持久化，将RDB文件内存和增量的AOF日志文件放在一起，这里的AOF日志不再是全量日志。而是自持久化开始到持久化结束的这段时间的增量日志，通常较小，重启效率因此大幅得到提升

加载的时候，首先会识别AOF文件是否以REDIS字符串开头，如果是就按照RDB格式加载，加载完成后继续按AOF加载剩余的部分

总结

本节内容主要讲解了Redis的持久化过程，一种是RDB快照方式，一种是AOF方式，RDB在数据安全上得不到满足，而AOF在恢复上的效率较慢，所以在4.0版本之后采用混合模式，也就是RDB和AOF混合在一起，满足了两个缺点，下次将带领大家继续探究Redis在安全性上的设计！

给大家的福利

零基础入门

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

bs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！