学习资料
学习的黑马程序员哔站项目黑马点评，用作记录和探究原理。
Redis缓存
缓存 ：就是数据交换的缓冲区，是存储数据的临时地方，读写性能较高
缓存常见的场景:
- 数据库查询加速：通过将频繁查询的数据缓存起来，减少对数据库的直接访问，提高查询效率。
- 网页内容缓存：将动态生成的网页内容缓存起来，减少服务器生成页面的次数，提高网页响应速度。
- 会话数据缓存：将用户会话数据缓存起来，支持分布式系统中的会话共享。
- 队列系统：将任务队列缓存起来，支持高效的任务调度和执行。
使用Redis缓存的流程
实际上，读取数据库是很消耗资源的。假设现在有一大批用户短时间内请求数据库，数据库此时将面临巨大的压力。为了缓解这种压力，可以使用Redis来缓存频繁访问的数据，减少对数据库的直接访问。
具体流程如下：
检查缓存：首先检查Redis缓存中是否存在所需数据。
如果缓存中存在数据，则直接返回数据给用户，结束流程。
如果缓存中不存在数据，则继续下一步。
查询数据库：从数据库中查询所需数据。
查询到数据后，将数据返回给用户，同时将数据写入Redis缓存，以便下次快速访问。
如果未查询到数据，则返回空或相应的提示信息。
更新缓存：当数据库中的数据发生变化时，需要同步更新Redis缓存中的数据，确保数据的一致性。通常可以使用以下两种策略：
主动更新：在数据库更新的同时，主动更新缓存中的数据。
被动更新：当检测到缓存中的数据已失效时，再次从数据库中查询数据并更新缓存。
更新策略问题
为了保证缓存一致问题，我们在选择更新策略的时候一般选择主动更新的策略，
被动更新不一致问题
因为被动更新会出现不一致情况，比如说我们现在将一个店铺信息存入数据库，策略选择的被动策略，但是查询店铺信息我们选择的是使用Redis缓存，此时永远不回去更新这个店铺，因为我页面呈递不出来这个店铺信息，怎么能去请求他然后查询数据库更新呢？这就出现不一致的情况了。
对于这种情况再进行一个说明，我这边说的场景就是说我们把这个商品的列表信息存入Redis，当添加一个新的商品之后，缓存中没有，那么前端中就指定不会有，此时就很尴尬的一个场景。但是说一般不会这样玩，一般只是把商品详情信息存入Redis，商品列表还是查询数据库，毕竟不是很多，并且这样的话避免出现不同步问题。
主动更新 缓存更新时机选择
主动更新的时候时机选择也是比较重要的，当我更新数据库一条消息的时候，此时我是选择先将数据存入数据库还是说先将Redis中的数据删除？ 或者我向数据库添加一个消息，我是先存入数据库，还是先存入Redis中呢？
我们来看一下这张图
先删除缓存再更新数据库
场景先删除缓存，然后操作更新数据库，这个时候我们面临一个问题，由于就是说第一次请求肯定是先请求缓存中的，当缓存没有的时候此时请求数据库，我们假设第一个用户A此时更新了数据库中一件商品的信息，选择先把缓存中旧的信息删除，然后将数据库更新，那么此时用户A更新数据库的时候，用户B来访问这个信息，先看缓存，缓存中没有，那么此时肯定得查询数据库，数据库中还没更新成功，那么这个数据查询依旧是旧的值，这样不就出现问题了吗，这样的话就出现一个场景，由于就是更新数据库耗时久，那么这个时候出现大量请求这个内容，那么持续请求数据库，会造成压力，二就是此时数据也不一致。
先更新数据库，再删除缓存。
在处理缓存和数据库更新时，我们选择先更新数据库，然后删除缓存。这样做有几个优势：
降低数据库查询压力：
当用户访问该信息时，缓存中仍然是旧的信息。虽然这意味着短时间内用户可能获取到的是旧数据，但由于缓存命中，减少了对数据库的直接查询，降低了数据库的查询压力。
确保数据一致性：
一旦数据库更新完成，再删除缓存。此时，缓存被清除，下一次用户访问该信息时，会从数据库读取最新的数据并重新加载到缓存中。这种方式保证了数据的一致性，确保缓存中不会出现过时的数据。
针对缓存不一致问题我了解的解决方案有以下几种：
- 延迟双删策略（Double Deletion with Delay）
在更新数据库后，通过延迟再次删除缓存以确保数据的一致性。
// 更新数据库
updateDatabase();
// 删除缓存
deleteCache();
// 延迟一段时间后再删除缓存
Thread.sleep(500); // 延迟时间根据具体场景调整
deleteCache();
- 互斥锁机制（Mutex Locking Mechanism）
使用分布式锁来避免多个请求同时更新数据库或缓存。确保只有一个请求可以访问数据库并更新缓存。
String value = getCache(key);
if (value == null) {
if (lock(key)) {
try {
value = queryDatabase();
setCache(key, value);
} finally {
unlock(key);
}
} else {
// 等待锁释放后重试
Thread.sleep(50); // 重试时间根据具体场景调整
value = getCache(key);
}
}
return value;
- 缓存预热（Cache Warming）
在应用启动时或缓存失效时，预先加载常用的数据到缓存中，减少缓存穿透的概率。
// 在应用启动时加载常用数据到缓存
loadCommonDataToCache();
- 读写分离（Read-Write Separation）
将读操作与写操作分离，写操作使用主数据库，读操作使用从数据库，减轻数据库压力。
// 写操作使用主数据库
updateMainDatabase();
// 读操作使用从数据库
value = queryReadReplicaDatabase();
缓存场景会出现的问题
缓存穿透
是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。常见的解决方案有两种。
- 缓存空对象
也就是说我们此时查询数据库发现这个内容是空的，我们避免下一次有人把继续访问这个空的内容，然后造成服务器压力，那么此时我们把这个空的内容缓存到Redis中，此时当再次请求这个内容的时候，请求的是Redis中的内容，对服务器压力会降低很多。
步骤：
客户端请求数据。
检查缓存，发现没有命中。
查询数据库，发现数据不存在。
将空对象（如null或者特殊标识）缓存到Redis中，并设置一个合理的过期时间。
当再次请求这个内容时，直接从Redis中获取空对象，减少数据库压力。
- 布隆过滤
布隆过滤器是一种概率型数据结构，可以高效地判断某个元素是否在一个集合中。通过将所有可能存在的缓存键值存储在布隆过滤器中，可以快速判断某个请求是否是无效的（即数据库中也不存在），从而减少对数据库的查询。
步骤：
初始化布隆过滤器，将所有可能存在的键值添加到过滤器中。
客户端请求数据时，先检查布隆过滤器。
如果布隆过滤器判断数据不存在，直接返回空结果，避免查询数据库。
如果布隆过滤器判断数据可能存在，再查询缓存和数据库。
示例代码：
// 初始化布隆过滤器，并添加所有可能存在的键值
BloomFilter<String> bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()), 1000000);
bloomFilter.putAll(getAllPossibleKeys());
String key = getRequestKey();
if (!bloomFilter.mightContain(key)) {
// 布隆过滤器判断数据不存在，直接返回空结果
return null;
}
String value = getCache(key);
if (value == null) {
value = queryDatabase(key);
if (value == null) {
// 数据不存在，缓存空对象
setCache(key, "NULL", 300); // 300秒过期时间，可根据具体情况调整
} else {
// 数据存在，缓存实际数据
setCache(key, value);
}
}
if ("NULL".equals(value)) {
// 返回数据不存在的响应
return null;
}
return value;
缓存穿透的解决方案
- 缓存null值
- 布隆过滤
- 增强id的复杂度，避免被猜测id规律
- 做好数据的基础格式校验
- 加强用户权限校验
缓存雪崩
缓存雪崩主要是由于一段时间内，缓存的key值全部失效，也就是缓存期结束，导致大量请求到达数据库，带来巨大的压力。
那么这个场景的解决方案也很简单。
缓存击穿
缓存击穿被称为热点key 问题，就是一种被高并发访问并且缓存重建业务较复杂的key,失效了，大量请求访问的瞬间给数据库带来巨大压力
假设一家店突然推出一家新的菜品，但是说此时缓存过程中数据库更新了，将旧的Redis缓存删除之后，此时大量用户访问这个内容的话会出现一个场景，形成一个闭环。
这样不就出现大量请求数据库的场景了吗？我们要怎么避免这个内容呢
这个解决方案有两种：
方案一：使用互斥锁
相信大家在学习javase阶段的多线程肯定面临一个问题，也就是说多线程抢票问题，当不加锁的情况下会出现超卖问题，加一个锁一次只能抢一个，这样会更好。这个位置也就是说更新缓存的时候加一个锁，让其他业务线程不进行更新操作。
但是说这个锁应该选什么呢？现在既然在使用Redis，那么这个时候我们就直接选择使用Redis中字符串类型的SETNX 作为互斥锁。
方案二：使用逻辑过期
将Redis缓存中的内容设置一个逻辑过期字段，保证在读取缓存时，可以判断数据是否过期。这样可以减少缓存穿透和击穿问题。
具体步骤：
客户端请求数据。
检查缓存，获取缓存数据和逻辑过期时间。
如果数据未过期，直接返回缓存数据。
如果数据已过期或缓存未命中：
启动一个异步线程更新缓存。
返回旧数据或提示正在更新中。
缓存击穿 - Java代码解决
互斥锁解决
互斥锁这边使用的锁对象是Redis 中String类型的SETNX，由于其一个键只能赋值一次，这样的话符合预期场景。
这样写的话，会保证不会出现连续查询数据库，保证当一个值改变之后只更新一次数据库操作。
其实也就是说，当我线程一更新的时候，我先判断指定的锁的key是否存在，存在将他设置，此时相当于线程一获取了锁，那么县城二进入的时候便不可以获取道这个锁对象，那么线程二就需要等待，等待之后重试。直到缓存命中才结束。
场景：书写接口查询店铺的详细信息。其中id是店铺的标识
public Shop queryWithPassThrough(Long id) {
// 店铺在Redis中的key规范 同一前缀 + 店铺id
String key = RedisConstants.CACHE_SHOP_KEY + id;
// 查询redis缓存中 是否会有这个内容
String s = stringRedisTemplate.opsForValue().get(key);
// 存在 直接返回
if (StrUtil.isNotBlank(s)) {
return JSONUtil.toBean(s, Shop.class);
}
/*
* 既然不是null 那一定是 ""
* 这样的话我们需要进行 返回错误了 防止继续去查询数据库
* 这个是缓存穿透的一个防护手段 上面讲解过了
* */
if (s != null) {
return null;
}
// 实现缓存重建
// 获取互斥锁
String lockKey = RedisConstants.LOCK_SHOP_KEY + id;
Shop byId = null;
try {
// 获取锁 直接使用String中的setnx即可 判断是否获取成功
boolean b = tryLocal(lockKey);
// 失败
if (!b) {
// 休眠
Thread.sleep(50);
// 重试 重新调用递归
queryWithPassThrough(id);
}
// 不存在 查询数据库
byId = getById(id);
// 不存在 返回错误
if (byId == null) {
/*
* 写入空值内容 防止 持续 缓存穿透 造成服务器资源浪费
* 时间设置成 2 min
* */
stringRedisTemplate.opsForValue().set(key, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
// 数据库存在
// 将数据放入redis中
/*
* 这个位置书写一个超时设置 避免资源浪费
* 主要是为了解决
* 缓存不一致问题
* */
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(byId), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
// 返回数据
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
// 释放锁
delLocal(lockKey);
}
// 返回店铺详情
return byId;
}
private boolean tryLocal(String key) {
Boolean judge = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
return BooleanUtil.isTrue(judge);
}
private void delLocal(String key) {
stringRedisTemplate.delete(key);
}
逻辑删除
逻辑删除 ，也就是向储存的数据中加一个字段，这个字段就是过期时间，这边设置的实体是按照这种格式设计的内容。
package com.hmdp.utils;
import lombok.Data;
import java.time.LocalDateTime;
/*
* 逻辑过期时间实体
* */
@Data
public class RedisData {
private LocalDateTime expireTime;
// 存入的数据
private Object data;
}
我们缓存重建的时候，需要将逻辑过期时间重置，所以这个时候我们需要封装一个方法来重置逻辑过期时间。
public void saveShopToRedis(Long id, Long seconds) {
// 1.查询店铺数据
Shop byId = getById(id);
RedisData redisData = new RedisData();
redisData.setData(byId);
// 2.封装逻辑过期时间
redisData.setExpireTime(LocalDateTime.now().plusSeconds(seconds));
// 3.写入redis
stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
}
逻辑过期代码 - 其中缓存重建新开一个线程使用。
public Shop queryWithLogicalExpire(Long id) {
String key = RedisConstants.CACHE_SHOP_KEY + id;
// 查询redis缓存中 是否会有这个内容
String s = stringRedisTemplate.opsForValue().get(key);
// 存在 直接返回
if (StrUtil.isNotBlank(s)) {
return JSONUtil.toBean(s, Shop.class);
}
/*
* 既然不是null 那一定是 ""
* 这样的话我们需要进行 返回错误了 防止继续去查询数据库
* 这个是缓存穿透的一个防护手段
* */
if (s != null) {
return null;
}
RedisData bean = JSONUtil.toBean(s, RedisData.class);
Shop shop = JSONUtil.toBean((JSONObject) bean.getData(), Shop.class);
LocalDateTime localDateTime = bean.getExpireTime();
if (localDateTime.isAfter(LocalDateTime.now())) {
return shop;
}
String lockKey = RedisConstants.LOCK_SHOP_KEY + id;
boolean b = tryLocal(lockKey);
if (b) {
try {
CACHE_REBUILD_EXCUTOR.submit(() -> {
this.saveShopToRedis(id, RedisConstants.CACHE_SHOP_TTL);
});
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
// 释放锁
delLocal(lockKey);
}
}
return shop;
}
