redis缓存，2024年最新网络安全开发面试宝典

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

这里所说的"触手可及"是个相对的概念.
我们知道，对于硬件的访问速度来说，通常情况下
CPU寄存器>内存>硬盘>网络
那么硬盘相对于网络是"触手可及的",就可以使用硬盘作为网络的缓存.
内存相对于硬盘是"触手可及的",就可以使用内存作为硬盘的缓存.
CPU寄存器相对于内存是"触手可及的",就可以使用CPU寄存器作为内存的缓存.

对于计算机硬件来说,往往访问速度越快的设备,成本越高,存储空间越小
缓存是更快，但是空间上往往是不足的.因此大部分的时候,缓存只放一些热点数据(访问频繁的数据),就非常有用了.

关于"二八定律"
20%的热点数据，能够应对80%的访问场景.
因此只需要把这少量的热点数据缓存起来，就可以应对大多数场景,从而在整体上有明显的性能提升.

2.使用Redis作为缓存

在一个网站中，我们经常会使用关系型数据库(此如MySQL)来存储数据.
关系型数据库虽然功能强大,但是有- -个很大的缺陷，就是性能不高. (换而言之，进行一次查询操作消耗的系统资源较多).
为什么说关系型数据库性能不高?
1.数据库把数据存储在硬盘上，硬盘的IO速度并不快.尤其是随机访问.
2.如果查询不能命中索引，就需要进行表的遍历,这就会大大增加硬盘I0次数. 
3.关系型数据库对于SQL的执行会做一系列的解析，校验，优化工作.
4.如果是一些复杂查询，比如联合查询，需要进行笛卡尔积操作，效率更是降低很多.
5. …

因此,如果访问数据库的并发量比较高,对于数据库的压力是很大的,很容易就会使数据库服务器宕机.
为什么并发量高了就会宕机?
服务器每次处理一个请求， 都是需要消耗一-定的硬件 资源的.所谓的硬件资源包括不限于CPU,
内存，硬盘,网络带…
一个服务器的硬件资源本身是有限的.一个请求消耗一份资源， 请求多了，自然把资源就耗尽了.后续的请求没有资源可用，自然就无法正确处理.更严重的还会导致服务器程序的代码出现崩溃.
如何让数据库能够承担更大的并发量呢?核心思路主要是两个:
●开源: 引入更多的机器，部署更多的数据库实例,构成数据库集群. (主从复制，分库分表等…)
●节流:引入缓存， 使用其他的方式保存经常访问的热点数据，从而降低直接访问数据库的请求数量

实际开发中,这两种方案往往是会搭配使用的.

Redis就是一个用来作为数据库缓存的常见方案.
Redis访问速度比MySQL快很多.或者说处理同一个访问请求，Redis消耗的系统资源比MySQL少很多.因此Redis能支持的并发量更大.
●Redis数据在内存中，访问内存比硬盘快很多.
●Redis只是支持简单的key-value存储，不涉及复杂查询的那么多限制规则.
就像一个"护盾"一样,把MySQL给罩住了.

●客户端访问业务服务器，发起查询请求.
●业务服务器先查询Redis,看想要的数据是否在Redis中存在.
        如果已经在Redis中存在了，就直接返回.此时不必访问MySQL了.
        如果在Redis中不存在，再查询MySQL.
按照上述讨论的"二八定律" ,只需要在Redis中放20%的热点数据,就可以使80%的请求不再真正查
询数据库了.
当然，实践中究竟是"二八",还是"一九",还是"三七",这个情况可能会根据业务场景的不同,存在差
异.但是至少绝大多数情况下，使用缓存都能够大大提升整体的访问效率,降低数据库的压力.

注意!
缓存是用来加快"读操作"的速度的.如果是"写操作",还是要老老实实写数据库,缓存并不能提高性能.

3.缓存的更新策略

接下来还有一个重要的问题,到底哪些数据才是"热点数据"呢?

1)定期生成
每隔一定的周期(比如一天/一周/一个月),对于访问的数据频次进行统计.挑选出访问频次最高的前N%的数据.

以搜索引擎为例.
用户在搜索引擎中会输入一个"查询词",有些词是属于高频的，大家都爱搜(鲜花，蛋糕，同城交
友，不孕不育…有些词就属于低频的，大家很少搜.
搜索引擎的服务器会把哪个用户什么时间搜了啥词，都通过日志的方式记录的明明白白.然后
每隔一段时间对这期间的搜索结果进行统计(日志的数量可能非常巨大，这个统计的过程可能
需要使用hadoop或者spark等方式完成).从而就可以得到"高频词表"

这种做法实时性较低.对于一些突然情况应对的并不好.
比如春节期间, “春晚"这样的词就会成为非常高频的词.而平时则很少会有人搜索"春晚”.

2)实时生成
先给缓存设定容量上限(可以通过Redis配置文件的maxmemory 参数设定).
接下来把用户每次查询:
●如果在Redis查到了,就直接返回.
●如果Redis中不存在,就从数据库查,把查到的结果同时也写入Redis.
如果缓存已经满了(达到上限),就触发缓存淘汰策略,把- -些"相对不那么热门"的数据淘汰掉.
按照上述过程，持续一段时间之后Redis内部的数据自然就是"热门数据"了.

通用的淘汰策略主要有以下几种: 
下列策 略并非局限于Redis,其他缓存也可以按这些策略展开.
FIFO (First In First Out)先进先出
把缓存中存在时间最久的(也就是先来的数据)淘汰掉.
LRU (Least Recently Used)淘汰最久未使用的
记录每个key的最近访问时间.把最近访问时间最老的key淘汰掉.
LFU (Least Frequently Used)淘汰访问次数最少的

Random随机淘汰
从所有的key中抽取幸运) L被随机淘汰掉.

这里的淘汰策略,我们可以自己实现.当然Redis也提供了内置的淘汰策略,也可以供我们直接使用.

Redis内置的淘汰策略如下:
●volatile-lru当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU (最近最少使用)算法进行淘汰
●allkeys-lru当内存不足以容纳新写入数据时，从所有key中使用LRU (最近最少使用)算法进行淘汰.
●volatile-lfu 4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key.
●allkeys-lfu 4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰.
●volatile- random 当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据.
●allkeys- random当内存不足以容纳新写入数据时，从所有key中随机淘汰数据.
●volatile-ttl在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰.
(相当于FIFO,只不过是局限于过期的key)
●noeviction默认策略，当内存不足以容纳新写入数据时，新写入操作会报错.

整体来说Redis提供的策略和我们上述介绍的通用策略是基本一致的. 只不过Redis这里会针对"过期
key"和"全部key"做分别处理.

4.缓存预热，缓存穿透,缓存雪崩和缓存击穿

关于缓存预热(Cache preheating)
什么是缓存预热
使用Redis作为MySQL的缓存的时候,当Redis刚刚启动,或者Redis大批key失效之后，此时由于
Redis自身相当于是空着的，没啥缓存数据，那么MySQL就可能直接被访问到,从而造成较大的压力.
因此就需要提前把热点数据准备好，直接写入到Redis中.使Redis可以尽快为MySQL撑起保护伞.
热点数据可以基于之前介绍的统计的方式生成即可.这份热点数据不一定非得那么"准确",只要能帮助MySQL抵挡大部分请求即可.随着程序运行的推移,缓存的热点数据会逐渐自动调整,来更适应当前情况.

给大家的福利

零基础入门

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

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

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

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

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）

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

要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）**
[外链图片转存中…(img-ttUnV6yu-1713399586363)]

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