1、缓存和数据库同步方案
一般项目的同步都是基于数据库的CURD操作
- 数据新增:
数据新增直接新增到数据库
- 数据修改
先删除缓存中的对应数据
再修改数据库的数据
- 数据删除
删除缓存中对应数据
删除数据库的数据
- 数据查询
先进行缓存查询,存在数据即返回查询的数据.
若缓存中不存在数据则查询数据库.
若数据库存在数据则返回数据库并同步更新到缓存.
若缓存和数据库都不存在数据返回空
2、缓存穿透
如图:比如说这是我们的APP程序,红色是我们的Redis,蓝色是我们的DB,我们的查询是从redis,是这一个层面的,查不到我们就去查DB当中缓存穿透的一个概念是指什么意思呢?甚至于我们的应用程序端在访问数据的过程当中,穿过了缓存的这个中间件,直接访问我们的DB形成的DB的访问压力,这个东西就叫做缓存穿透,就是我们的http请求,他穿过了Redis是或者说无数个客户端请求是直接从DB当中进行数据获取的一个过程,就叫做缓存穿透。(图潦草,凑合看)
3、拓:
1. 如何在大数据集中快速判断指定元素是否存在
思路:需要一个空间占用小并且能快速查找的容器
答**:用bitmap+哈希函数存储**
那么问题来了:如何将元素装进容器呢? 答: 哈希函数
为什么用哈希函数?因为哈希函数满足两个特性:
1. 确定性(即传入一个元素,计算多次的结果一致)
2. 允许任意的输入并且是固定长度的输出
但此时会出现一个问题:
如果不同的元素,通过hash函数计算生成同一的地址值,就会产生冲突
也叫所谓的哈希碰撞问题
解决方法:
- 1.开放地址法
-
开放地执法有一个公式:Hi=(H(key)+di) MOD m i=1,2,…,k(k<=m-1) 其中,m为哈希表的表长。di 是产生冲突的时候的增量序列。如果di值可能为1,2,3,…m-1,称线性探测再散列。
如果di取1,则每次冲突之后,向后移动1个位置.如果di取值可能为1,-1,2,-2,4,-4,9,-9,16,-16,…kk,-kk(k<=m/2),称二次探测再散列。
如果di取值可能为伪随机数列。称伪随机探测再散列。
- 2.再哈希法 -
当发生冲突时,使用第二个、第三个、哈希函数计算地址,直到无冲突时。 比如上面第一次按照姓首字母进行哈希,如果产生冲突可以按照姓字母首字母第二位进行哈希,再冲突,第三位,直到不冲突为止
-
使用多个哈希函数生成地址值,即元素通过三个哈希函数计算出三个地址值,值都存入为1。当查询数值时候,这三个地址值都为1的时候,我们才判定此元素存在
-
缺点:存址序列增长,计算时间增加,随着哈希函数使用的增加,效率降低
而且,冲突问题不能100%的规避,只能说随多函数使用,冲突概率越来低
- 3.链地址法(拉链法)
- 将所有关键字为同义词的记录存储在同一线性链表中。 当查询元素是否存在时,查找数组没有的话顺着数组后的链表继续查找直到为空。
如下:
优点:
①拉链法处理冲突简单,且无堆积现象,即非同义词决不会发生冲突,因此平均查找长度较短;
②由于拉链法中各链表上的结点空间是动态申请的,故它更适合于造表前无法确定表长的情况;
③开放定址法为减少冲突,要求装填因子α较小,故当结点规模较大时会浪费很多空间。而拉链法中可取α≥1,且结点较大时,拉链法中增加的指针域可忽略不计,因此节省空间;
④在用拉链法构造的散列表中,删除结点的操作易于实现。只要简单地删去链表上相应的结点即可。而对开放地址法构造的散列表,删除结点不能简单地将被删结 点的空间置为空,否则将截断在它之后填人散列表的同义词结点的查找路径。这是因为各种开放地址法中,空地址单元(即开放地址)都是查找失败的条件。因此在 用开放地址法处理冲突的散列表上执行删除操作,只能在被删结点上做删除标记,而不能真正删除结点。
缺点:
指针需要额外的空间,故当结点规模较小时,开放定址法较为节省空间,而若将节省的指针空间用来扩大散列表的规模,可使装填因子变小,这又减少了开放定址法中的冲突,从而提高平均查找速度。
(此段摘自https://blog.csdn.net/zeb_perfect/article/details/52574915)
4.建立一个公共溢出区
假设哈希函数的值域为[0,m-1],则设向量HashTable[0…m-1]为基本表,另外设立存储空间向量OverTable[0…v]用以存储发生冲突的记录
正题:
缓存穿透可能是由一些原因导致的:比如恶意同一无效数据高频恶意请求、或者不同恶意数据高频请求
这些都会给我们的缓存带来很大压力,可能导致此问题的发生。
那我们有什么解决办法吗:
接下来我要介绍一下Boom Filter过滤
特点:不存在漏报,存在误报
这句话意思是:就是我查询一个元素说它存在,它其实可能不存在;但我说它不存在,它就一定是不存在