缓存穿透:用户多次查询数据库没有的数据,导致多次访问数据库,从而使数据库压力变大
解释:用户多次连续访问数据,比如说用户查询id为101的数据时,数据库是没有的,并且用户进行了多次查询id为101的数据,那么久数据库的压力就会 很大
如何防止缓存穿透:
为了防止用户多次访问数据库我就可以在缓存中存一个key为101,值为空的数据,并设置一个较短的ttl,那么用户在访问同一个id的并且数据库没有的数据时,就可以 从缓存中返回空数据,防止数据库压力过大,也就是防止缓存穿透。
缓存雪崩:缓存大批量同一时间失效,导致数据库访问压力大。
解释:
一般设置缓存的键值对时都是有ttl的,如果说同一批次查询出的数据设置的ttl一样,那么就会在同一时间失效, 导致数据库的访问量变大,
如何防止缓存雪崩:
我们可以将ttl的时间设置为一个基础时间加一个随机时间,让缓存不在同一时间内失效来防止缓存雪崩
缓存更新策略:
1.内存淘汰(不用自己维护,由redis的内存淘汰机制,当内存不足时删除部分数据)(一致性 差,无维护成本)
2.超时剔除(设置缓存的ttl时间,到期后自动删除缓存---问题:比如设置ttl时间为10分钟,在这期 间数据库发生变化导致数据不一致)(一致性一般,维护成本低)
3.主动更新策略(推荐)(一致性好,维护成本高)
a.在调用者更新数据库的同时更新redis(可控性比较高)(目前企业中使用的大多时这种方式)
3.1.1:操作缓存和数据库需要考虑三个问题
3.1.1.1:删除缓存还是更新缓存
更新缓存:每次更新数据库的时候更新缓存,对缓存的操作属于无效操作,(比如执 行了很多此更新,这个期间,没有从redis获取数据,redis就失去了作用)
删除缓存:更新数据库时使缓存的失效 (每次执行删除或者更新操作时删除对应的缓 存,保持一致性)
3.1.1.2:如何保证数据库和缓存的操作同时成功和同时失败
单体项目:通过事务来管理,保证同时成功,同时失败
分布式项目:通过TCC的分布式事务方案解决(还没学会,先放这吧)
3.1.1.3:先操作缓存还是先操作数据库
3.1.1.3.1 先删除数据再操作缓存(推荐)
存在的问题:
假如线程1执行了查询操作,查询id为99的数据,缓存中没有,那么该去数据库 查询了,在查询出结果为10但是没有写入缓存时,线程二执行了更新id为 99的数据,并写入缓存,数据库值为20,此时线程1执行了插入缓存的数据为 10,那么就会发生数据库缓存不一致的情况。
解决方案:
一般来说,数据库的更新操作是比较长的,写入缓存是很快的,就是说在执行线 程1去数据库查询出数据但是没有写入缓存,并且此时正好另外一个线程 在写入缓存的时间间隔内执行了更新操作的情况的可能性很小,但不是没有,这 种情况以为这更新的时间比写入缓存的时间短,我们可以考虑给写入缓 存设置一个最大的时间限制,如果超过这个时间,就可以重新查询一次数据库, 来更新数据
3.1.1.3.2先删除缓存再操作数据库(不推荐)
存在的问题:假如现在要更新数据id为100的值为20,线程1先删除了id为100的缓 存数据,还没有 去更新数据库,此时线程二查询了id为100的数据,缓存中 没 有,去数据库查询值为10,然后写如了缓存,此时线程1将数据数据更新 为 20,那么就导致了数据库数据和缓存不一致,而且这种情况的概率很 高,因为线程1更新数据库的速度是慢于线程二查询数据的速度的 。
b.缓存和数据库整合成一个服务(实现比较困难,不好找到一个现成的实现方案)
c.调用者 只操作缓存,由其他的线程异步的处理数据库(由于调用者只操作了缓存,速度很快,并且缓存的多次操作可以由线程进行批量插入进数据库,比较合适)(问题是可能存在缓存和数据库不 一致,另外数据都存在缓存中,万一缓存服务宕机可能导致数据丢失)
综上所述,企业中推荐使用主动更新策略来更新缓存,方式为在调用者更新数据库的同时更新redis。更新过程中需要考虑三个问题如3.1.1。