在高并发系统中，缓存穿透、缓存雪崩和缓存击穿是常见的性能瓶颈问题，既要理解它们的原理，也要掌握高效的解决方案。本文将从缓存一致性、优化策略及实际代码实现出发，带你深入探索Redis缓存问题的应对之道。
缓存穿透、缓存雪崩、缓存击穿的定义与影响
缓存穿透是指客户端请求的数据在缓存和数据库中都不存在，导致请求直接穿透到数据库，造成不必要的压力。
缓存雪崩则指大量缓存key在某一时刻同时失效或Redis服务宕机，引发数据库的高并发访问，可能导致系统崩溃。
缓存击穿是热点Key失效后，大量并发请求直接访问数据库，形成短暂的数据库压力高峰。
这三种问题虽然都与缓存失效相关，但其触发原因和影响范围各不相同。缓存穿透主要影响数据查询的效率，缓存雪崩可能导致系统整体崩溃，缓存击穿则是局部的高并发压力问题。在实际开发中，需要根据场景选择合适的解决方案。
缓存不一致问题的常见处理方案
在实际业务中，缓存和数据库的数据可能不一致，常见的解决方案有三种：
1. Cache Aside Pattern（人工编码方式）：缓存调用者在更新完数据库后再去更新缓存，也称之为双写方案。
2. Read/Write Through Pattern（系统本身处理）：系统负责缓存与数据库的同步，避免了人工编码的复杂性。
3. Write Behind Caching Pattern（异步更新）：调用者只操作缓存，其他线程异步处理数据库更新，实现最终一致性。
每种方案都有其适用场景和优缺点。Cache Aside Pattern实现简单，但需要开发者在每次更新数据库时手动更新缓存，容易遗漏。Read/Write Through Pattern由系统处理，保证了数据一致性，但增加了系统复杂度。Write Behind Caching Pattern通过异步处理降低了延迟，但可能会造成数据延迟问题。
数据库与缓存的双写一致性实现
为了确保数据库和缓存的双写一致性，我们建议采用先操作数据库，再删除缓存的策略，这样可以避免缓存中保留过时数据。
在代码层面，可以使用事务来保证数据库操作和缓存删除的原子性。例如，使用@Transactional注解，确保在数据库更新失败时，缓存不会被错误地删除。
@Override
@Transactional(rollbackFor = {Exception.class})
public ResultBean<Integer> update(ShopEntity param) {
Long id = param.getId();
if (id != null) {
return ResultBean.create(-1, "商铺id不允许为空！");
}
//1. 更新数据库
updateById(param);
//2. 删除缓存
stringRedisTemplate.delete(RedisConstants.CACHE_SHOP_KEY + id);
return ResultBean.create(0, "success", 1);
}
这里的关键是事务的使用，它能确保数据库更新成功后才会删除缓存，防止出现缓存和数据库数据不一致的情况。
解决缓存穿透的两种策略
缓存空对象
缓存空对象是一种简单有效的解决方案，其核心思想是：即使数据库中查询不到数据，也将一个空对象存入缓存。
优点是实现简单，维护方便，缺点则是内存占用较大，且可能导致短期不一致问题。例如，当数据库中数据被修改后，缓存中的空对象仍然存在，直到过期时间到达。
public ShopEntity queryWithPassThrough(Long id) {
String key = RedisConstants.CACHE_SHOP_KEY + id;
String shopJson = stringRedisTemplate.opsForValue().get(key);
if (StrUtil.isNotBlank(shopJson)) {
return JSONUtil.toBean(shopJson, ShopEntity.class);
}
if (shopJson != null) {
return null;
}
ShopEntity shopEntity = getById(id);
if (shopEntity == null) {
stringRedisTemplate.opsForValue().set(key, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shopEntity), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
return shopEntity;
}
这种方案适用于大多数场景，尤其在数据不存在的查询较多时，可以有效减轻数据库压力。
布隆过滤器
布隆过滤器是一种基于哈希的高效数据结构，用于快速判断一个数据是否存在于集合中。它的优点是内存占用较少，没有多余的key，但缺点是存在误判可能。
布隆过滤器的实现较为复杂，需要自行维护过滤器，同时需要考虑哈希冲突的问题。但在某些高并发场景下，布隆过滤器可以显著减少缓存穿透的可能性。
解决缓存击穿的两种策略
互斥锁方案
互斥锁的核心思想是：当缓存未命中时，只有第一个线程去数据库加载数据并重新写入缓存，其他线程则等待。
通过使用setnx方法（即setIfAbsent方法），我们可以实现互斥锁的逻辑。
public ShopEntity queryWithPassMutex(Long id) {
String key = RedisConstants.CACHE_SHOP_KEY + id;
String shopJson = stringRedisTemplate.opsForValue().get(key);
if (StrUtil.isNotBlank(shopJson)) {
return JSONUtil.toBean(shopJson, ShopEntity.class);
}
if (shopJson != null) {
return null;
}
ShopEntity shopEntity = null;
String lockKey = RedisConstants.LOCK_SHOP_KEY + id;
try {
boolean lock = tryLock(lockKey);
if (!lock) {
Thread.sleep(10);
queryWithPassMutex(id);
}
shopEntity = getById(id);
Thread.sleep(5);
if (shopEntity == null) {
stringRedisTemplate.opsForValue().set(key, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
} else {
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shopEntity), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
}
} finally {
unLock(lockKey);
}
return shopEntity;
}
互斥锁方案的优点是数据一致性好，但缺点是性能下降，因为查询请求会被串行化。在并发量不高的场景中，可以采用此方案，而在高并发场景中，则需要考虑更高效的方案。
逻辑过期方案
逻辑过期是一种通过在缓存中存储逻辑过期时间来解决缓存击穿问题的方法。它的核心思想是：将过期时间存储在缓存值中，而不是设置Redis的过期时间。
当查询缓存时，首先判断数据是否过期，如果过期则触发重建逻辑，否则直接返回缓存中的数据。
public ShopEntity queryWithPassLogic(Long id) {
String key = RedisConstants.CACHE_SHOP_KEY + id;
String shopJson = stringRedisTemplate.opsForValue().get(key);
if (StrUtil.isNotBlank(shopJson)) {
// 解析缓存中的数据
ShopEntity shopEntity = JSONUtil.toBean(shopJson, ShopEntity.class);
// 判断是否过期
if (shopEntity.getExpireTime() < System.currentTimeMillis()) {
// 触发重建逻辑
rebuildCache(id);
} else {
return shopEntity;
}
}
if (shopJson != null) {
return null;
}
ShopEntity shopEntity = getById(id);
if (shopEntity == null) {
stringRedisTemplate.opsForValue().set(key, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shopEntity), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
return shopEntity;
}
逻辑过期方案的优点是性能高，因为它避免了锁的开销，但缺点是重建期间可能返回脏数据。因此，需要权衡是否接受这种短暂不一致的问题。
缓存雪崩的解决方案
缓存雪崩是指大量缓存key在同一时间失效，导致数据库压力骤增。其解决方案包括：
- 设置随机TTL：为每个缓存key设置不同的过期时间，避免大量key同时失效。
- Redis集群：通过主从复制、哨兵模式等提高Redis服务的可用性。
- 降级限流策略：在缓存雪崩发生时，启动限流或降级机制，防止数据库被压垮。
- 多级缓存：在本地缓存（如Caffeine）和Redis之间构建多级缓存体系，缓解数据库压力。
其中，设置随机TTL是最常见且简单有效的方案。例如，将原本统一的过期时间，改为一个随机的数值范围，如TTL + 1000ms，以分散缓存失效的时间。
// 设置随机TTL示例
long randomTTL = RedisConstants.CACHE_SHOP_TTL + (long) (Math.random() * 1000);
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shopEntity), randomTTL, TimeUnit.MILLISECONDS);
这种方式可以有效避免缓存雪崩的发生，但需要开发者对缓存策略进行合理设计。
缓存更新策略详解
内存淘汰策略
Redis提供了多种内存淘汰策略，如noeviction、allkeys-lru、volatile-lru等，这些策略决定了当内存不足时，Redis如何选择淘汰的数据。
内存淘汰策略是Redis自动进行的，当内存达到设定的maxmemory时，Redis会根据策略选择淘汰的数据。例如，allkeys-lru会淘汰最近最少使用的数据，volatile-ttl则优先淘汰剩余时间较短的数据。
在实际应用中，根据业务需求选择合适的淘汰策略，可以有效优化内存使用和缓存性能。
超时剔除
超时剔除是指Redis在设置TTL后，自动删除过期的数据。这种方式适用于缓存数据有明确的过期时间，并且需要及时清理无效数据的场景。
超时剔除机制是Redis内部实现的，不需要开发者手动干预，但需要在设置缓存时合理配置TTL，避免数据过早失效或长期占用内存。
主动更新
主动更新是指在数据库数据发生变化时，手动删除或更新缓存。这种方案通常用于解决缓存与数据库不一致的问题，例如在更新数据库后，主动删除缓存以触发缓存重建。
主动更新的实现方式较为灵活，可以结合事务、定时任务等机制来保证更新的及时性。
缓存一致性实践中的注意事项
在实际开发中，缓存一致性问题需要特别注意。例如，先操作数据库再删除缓存可以保证数据的一致性，但如果数据库更新失败，缓存仍然会被删除，这可能导致缓存中出现无效数据。
因此，在代码中使用事务来保障数据库操作和缓存删除的原子性是关键。如果数据库更新失败，缓存不会被删除，从而避免数据不一致的问题。
此外，还需要考虑并发问题，如果多个线程同时更新数据库，可能会导致缓存删除不及时，进而引发缓存不一致。因此，在高并发场景中，需要结合互斥锁或逻辑过期等方案，确保缓存重建的有序性。
缓存优化与性能提升技巧
在实际应用中，缓存的优化不仅仅依赖于策略的选择，还需要关注缓存的性能问题。例如，慢查询分析和执行计划优化是提升数据库性能的关键，而缓存命中率则直接关系到系统的响应速度。
通过分析慢查询日志，可以定位数据库性能瓶颈，优化SQL语句，提升查询效率。同时，合理设置索引，避免全表扫描，也是提升查询性能的重要手段。
在缓存方面，除了上述策略外，还需要关注缓存的冷热分离和缓存的分片策略。例如，将高频访问的数据缓存到本地，低频数据缓存到Redis，可以显著提升系统的整体性能。
缓存策略的选型与应用场景
在实际项目中，缓存策略的选择应根据业务场景进行权衡。例如：
- 缓存穿透：适用于数据不存在的查询较多的场景，推荐使用缓存空对象或布隆过滤器。
- 缓存击穿：适用于热点数据失效后的高并发访问场景，推荐使用互斥锁或逻辑过期。
- 缓存雪崩：适用于缓存大量key失效的场景，推荐使用设置随机TTL或多级缓存。
此外，还需要考虑系统的可扩展性和容错能力。例如，读写分离和分库分表可以有效提升数据库的性能，而高可用架构可以确保系统的稳定性。
在实际开发中，建议采用混合策略，结合多种缓存技术，以达到最佳的性能和一致性保障。
缓存与数据库的一致性保障
在实际系统中，缓存与数据库的一致性保障是至关重要的。例如，事务机制可以确保缓存和数据库的操作要么都成功，要么都失败。
在单体系统中，事务的实现较为简单，可以直接使用数据库事务来保证一致性。但在分布式系统中，需要采用分布式事务方案，如TCC（Try-Confirm-Cancel），来确保多个服务之间的操作一致性。
此外，还需要关注缓存的更新策略，例如在数据库更新后，主动删除缓存，以避免缓存中出现过时数据。
在高并发场景中，互斥锁或逻辑过期等方案可以有效避免缓存击穿，而缓存空对象或布隆过滤器则可以解决缓存穿透问题。
通过合理配置缓存的TTL，并结合随机过期时间，可以有效避免缓存雪崩的发生。
高可用架构与缓存策略的结合
为了保障系统的高可用性，可以采用多级缓存、读写分离和分库分表等方案。
多级缓存：将高频访问的数据缓存到本地，低频数据缓存到Redis，可以显著提升系统的响应速度。
读写分离：通过将读请求和写请求分离，可以降低数据库的压力，提高系统的并发能力。
分库分表：在数据量较大的场景中，通过分库分表可以提升数据库的性能和可扩展性。
这些架构设计可以与缓存策略相结合，以达到最佳的性能和可用性保障。
总结与建议
在实际应用中，缓存穿透、缓存雪崩和缓存击穿是常见的性能问题，需要根据具体场景选择合适的解决方案。
缓存空对象适用于数据不存在的查询较多的场景，布隆过滤器适用于内存占用敏感的场景，互斥锁和逻辑过期则适用于数据一致性要求较高的场景。
对于缓存雪崩，设置随机TTL和多级缓存是常用的解决方案。
在数据库与缓存的一致性保障方面，事务机制和主动更新是关键。
综上所述，缓存策略的选型应结合业务需求和系统架构，合理配置缓存的TTL、淘汰策略和一致性保障机制，以达到最佳的性能和稳定性。
关键字列表：
缓存穿透, 缓存雪崩, 缓存击穿, 互斥锁, 逻辑过期, 布隆过滤器, 数据库一致性, Redis, 内存淘汰策略, 事务机制, 分库分表