Redis的缓存穿透，击穿的解决方案

Redis的缓存穿透、击穿是两个不同的缓存机制问题，在设计和使用Redis缓存系统时，我们需要考虑以下两种常见的问题：缓存穿透、缓存击穿。

缓存穿透（Cache Penetration）

定义：
缓存穿透：缓存穿透是指查询一个在缓存和数据库中都不存在的数据，用户不断发起这样的请求，由于缓存不会缓存这样的查询结果，每次请求都会去数据库查询，可能会导致数据库压力过大。缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会直接打到数据库。

影响：
数据库压力增大，性能下降。
可能导致系统崩溃。

解决方案：

• key校验+缓存空对象：

首先在接口层面判断key是否有效（如id<=0或者校验key的长度等），这样会在接口层面拦掉一部分不合规则的请求。如果校验通过后，去查询数据库，当发现数据在数据库中不存在时，也将其存入Redis中，但value为空。
优点：实现简单，维护方便。
缺点：额外的内存消耗，可能造成短期的不一致。

• 布隆过滤器：

使用布隆过滤器判断请求的数据是否可能存在于Redis中。
优点：内存占用较少，没有多余key。
缺点：实现复杂，存在误判可能。

缓存击穿（Cache Breakthrough）

定义：
缓存击穿是指缓存中某个热点数据失效，此时有大量并发请求同时访问这个失效的数据，导致这些请求直接访问数据库，造成数据库压力过大，甚至导致数据库崩溃。

影响：
数据库承受高并发压力，可能导致崩溃。

解决方案：

• 锁机制：

使用锁机制或分布式锁机制，避免大量并发请求同时访问失效的热点数据。例如：如果未命中缓存，先获取互斥锁，获取锁之后要再次检查缓存，如果还是未命中进行缓存重建，这样当其他线程来的时候就会获取锁失败，这时我们让这个线程休眠一会，重新查询缓存，如果命中就返回，如果没命中再次尝试获取锁，假设这次获取锁成功了，还是再次检查缓存，如果未命中重建缓存。

优点：

可以有效防止多个请求同时访问数据库。
实现简单，可以利用Redis的分布式锁或其他锁机制。

缺点：

可能增加系统的响应时间，因为请求需要等待锁释放。
如果锁的粒度太粗，可能会导致性能瓶颈。

• 逻辑过期：

不设置TTL，而是设置逻辑上过期标识，需要过期时直接删除标识。

优点：

数据持久性：不设置TTL意味着数据将永久存储在Redis中，直到被显式删除或Redis实例被关闭。这对于需要长期存储的数据来说是有益的，因为它确保了数据的持久性。
减少过期检查的开销：Redis需要定期检查键的TTL以确定哪些键已经过期，并从缓存中删除它们。对于不设置TTL的键，Redis不需要执行这个过期检查，从而减少了CPU的开销。

缺点:

内存消耗：不设置TTL可能导致Redis内存中的数据持续增长，最终耗尽所有可用内存。这可能需要定期手动清理不再需要的数据，或者监控Redis的内存使用情况并采取适当的措施。

数据陈旧：没有TTL的缓存数据可能会变得陈旧或过时，因为它们永远不会自动过期。这可能需要额外的逻辑来定期更新或刷新缓存数据。

无法利用LRU等缓存淘汰策略：Redis提供了多种缓存淘汰策略（如LRU、LFU等），用于在内存不足时自动删除一些缓存项。不设置TTL的缓存项将不会被这些策略考虑，因为它们永远不会过期。