缓存击穿的破坏力与永不过期的防击穿逻辑
缓存击穿是指某个被高并发访问的热点key在缓存中突然过期，而此时大量的请求会同时落到数据库上，可能瞬间压垮存储层。与缓存穿透和雪崩不同，击穿的矛头明确指向单一热点数据，因此它的破坏力在秒杀、活动首页等场景下尤为致命。常见的应对手法是互斥锁：当发现缓存不存在时，用一个分布式锁保证仅一个线程回源数据库并重建缓存。这种方案可以保住数据库，但会引入锁竞争、超时管理以及大量等待线程的资源占用，实现上并不轻松。
另一种思路则更直接——既然过期是击穿的根源，那就让热点key永不设置过期时间。在Redis中，我们可以通过PERSIST命令移除已有的TTL，或从一开始写入key时就不带EXPIRE。这样，缓存永远不会因为时间流失而被淘汰，所有读请求都会直接从Redis获取数据，数据库得到彻底保护。但问题立即浮现：数据如果永不过期，当数据库里的原始数据发生修改时，缓存并不会主动感知，用户就会读到旧数据，甚至可能是已经失效的业务状态，这种不一致在敏感场景下完全不可接受。
所以，“永不过期”并不是放弃更新，而是将缓存失效的控制权从被动的时间维度转移到主动的业务维度。你不能再指望Redis自动帮你淘汰，而必须自己设计一套更新机制，在数据库变更时或变更后，立刻刷新对应的缓存。这种模式在概念上属于“主动缓存更新”，与传统的被动过期形成鲜明对比。理解了这一点，才能正确设计出既能防击穿又能保一致性的方案。
热点key永不过期的三种实现模式
最简单的做法是写操作驱动更新。当业务代码执行更新数据库的SQL后，立即同步更新Redis中的缓存数据。这种方式看似直接，但需要保证“写数据库”和“写缓存”两个操作的一致性。在单机事务环境下，如果更新数据库成功但Redis更新失败，缓存中便遗留了旧值；反过来，若先删缓存再更新数据库，则可能出现缓存击穿。实际落地时更多采用先更新数据库，然后以可靠的方式刷新缓存，例如使用可靠消息或监听数据库binlog来异步更新。对于严格一致性要求的场景，可以考虑将Redis更新放入数据库事务的提交后逻辑中，利用本地事务表确保最终一定执行。
第二种模式是写入队列异步刷新。引入一个消息队列，当数据库数据发生变化时，将变更事件（如商品ID、新价格）发送到消息队列。一个独立的消费者监听队列，然后负责将最新数据写入Redis。这样做的好处是解耦了写操作与缓存更新的延迟，即使Redis暂时不可用，也可以通过消息重试保证最终一致性。同时，由于缓存更新被解耦，可以更方便地控制并发、限流和重试策略。代码示例如下：
// 数据库更新成功后发送消息
public void updateProduct(Product product) {
productDao.update(product);
Message msg = new ProductUpdateMessage(product.getId(), product.getPrice());
messageQueue.send(msg);
}
// 消费者侧更新缓存
public class CacheConsumer {
public void handle(ProductUpdateMessage msg) {
Product product = productDao.findById(msg.getProductId());
String cacheKey = "product:" + product.getId();
jedis.set(cacheKey, JSON.toJSONString(product));
jedis.persist(cacheKey); // 确保没有TTL
}
}
第三种模式是“逻辑过期”与物理永不过期结合。虽然key在Redis中不设置过期时间，但我们可以在value内部维护一个过期时间戳，比如一个JSON字段包含expireAt。业务代码读取缓存时，先判断当前时间是否超过了逻辑过期时间。如果过期了，则启动一个异步任务去刷新缓存，但当前请求仍然返回旧值（防止穿透）。这实际上是把“物理永不过期”与“逻辑过期”融合到了一起，可以在数据陈旧容忍度较高的场景（如商品详情页）下使用，既不会因为缓存过期而击穿，又能在一段时间后自动拉取新数据。下面是读取时的伪代码：
public Product getProduct(String productId) {
String cacheData = jedis.get("product:" + productId);
ProductCache cache = JSON.parseObject(cacheData, ProductCache.class);
// 逻辑过期则异步刷新，当前返回旧数据
if (cache.getExpireAt() < System.currentTimeMillis()) {
asyncRefresh(productId);
}
return cache.getProduct();
}
private void asyncRefresh(String productId) {
// 使用一个锁来防止并发刷新
if (lock.tryLock(productId)) {
try {
Product newData = productDao.findById(productId);
ProductCache newCache = new ProductCache(newData,
System.currentTimeMillis() + refreshInterval);
jedis.set("product:" + productId, JSON.toJSONString(newCache));
jedis.persist("product:" + productId);
} finally {
lock.unlock(productId);
}
}
}
无论采用哪种模式，你都需要为这些永不过期的key建立一套生命周期管理规则。可能存在这样的情况：过去的热点key变得不再热门，但因为永不过期一直占用内存。因此，建议搭配全量或增量扫描任务，对于那些长时间不再被访问且非核心的数据，手动删除或降级其优先级。同时，结合Redis的内存淘汰策略（例如volatile-lfu无法作用于无过期key，需用allkeys-lfu），确保内存使用不会失控。
数据一致性的多层保障与生产注意事项
无论消息驱动还是双写，网络抖动、服务重启都可能导致缓存更新丢失。一个实用的弥补手段是定期全量刷新：在业务低峰期，通过定时任务从数据库中读取全部热点数据并批量更新到Redis。这种做法并不优雅，却能大幅度降低长时间不一致的概率。你可以结合版本号机制：数据库行上增加一个version字段，每次更新时递增，缓存中也存储该版本号。定时刷新或消费消息更新时，先检查缓存中的版本号是否小于数据库当前版本，仅当确实落后时才执行覆盖，避免并发更新的覆盖问题。
在微服务架构中，如果缓存更新由多个服务负责，可能会出现一条更新消息被不同消费者重复处理，或者同一个key被并发修改。通过分布式锁（如Redisson）来控制同一key的串行化更新，可以有效避免写写冲突。但要注意锁的颗粒度和超时时间，避免因锁持有过久而影响读性能。另一种方式是使用Redis的Lua脚本来实现原子的“检查版本并更新”操作：
local key = KEYS[1]
local newVersion = ARGV[1]
local newValue = ARGV[2]
local currentVersion = redis.call('HGET', key, 'version')
if not currentVersion or tonumber(currentVersion) < tonumber(newVersion) then
redis.call('HSET', key, 'version', newVersion, 'data', newValue)
redis.call('PERSIST', key)
return 1
else
return 0
end
通过这一脚本，即便多个客户端同时尝试更新，也只会有一个成功的写入，不仅保证了版本递增的正确性，同时也省去了分布式锁的额外开销。
还需要考虑缓存与数据库双写时的时序问题。经典的做法是“先更新数据库，再删除缓存”（而非更新缓存），试图用删除来逼迫下次读时重建最新数据。但在永不过期模式下，我们恰恰希望避免缓存被删除而引发击穿，因此更倾向于直接更新缓存。为了处理并发时序，可以采用“先标记刷新中”的策略：更新数据库成功之后，将缓存标记为refreshing状态，然后异步拉取最新数据写入。这段时间内的读请求看到refreshing标记，可以选择短时间自旋等待或直接回退到数据库查询（仅在极短时间窗口内）。虽然实现复杂，但能有效抑制短暂的数据不一致窗口。
最后，监控与告警不可缺失。统计每个热点key的最后更新时间与数据库最后变更时间的差异，一旦超出阈值则触发通知。同时观察Redis的内存使用率、命中率以及逻辑过期刷新任务的失败率，迅速发现更新链路中的异常。当发现长时间无法更新的key时，应该及时在缓存中注入一个有限的逻辑过期时间，暂时放弃永不过期保护，改为由互斥锁接管，以防止更大的数据错误扩散。
热点key永不过期是一把双刃剑：用得好，你可以在极高并发下维持近乎100%的缓存命中，把数据库保护得严严实实；用不好，陈旧数据会悄悄污染业务。选择哪一种更新模式，取决于你的业务对一致性的敏感度、系统复杂度承受力以及团队的运维能力。没有银弹，但结合本文的策略组合，你完全可以设计出一套坚固且可控的高可用缓存体系。