mysql在高并发下如何防止缓存击穿_结合Redis实现逻辑过期

首页

数据库

热心网友

转载

2026-04-28

缓存击穿：当热点Key失效时，数据库如何扛住“万箭齐发”？

mysql在高并发下如何防止缓存击穿_结合Redis实现逻辑过期

先明确一个核心概念：缓存击穿，它既不是大面积的缓存雪崩，也不是针对不存在数据的缓存穿透。它更像一次精准的“斩首行动”——当某个万众瞩目的热点Key在Redis中过期的那一刹那，海量并发请求瞬间发现缓存失效，齐刷刷地涌向MySQL，足以在顷刻间让数据库压力飙升。典型的场景？想想秒杀商品的详情页、实时更新的热搜榜单，或者配置中心里被高频读取的核心参数。

问题的根源，往往就藏在最常用的EXPIRE或SETEX命令里。为Key设置一个固定的生存时间（TTL）看似合理，但一旦这个过期时间点与流量洪峰不期而遇，后果可想而知。

为什么逻辑过期比物理过期更合适高并发场景

物理过期依赖Redis自动删除Key，时机完全不可控。而逻辑过期则玩了个“障眼法”：它把真正的过期时间“藏”进Value里。比如，存储一个JSON结构：{"data": "...", "expireAt": 1717023600000}。这样一来，Redis的Key本身设置为永不过期，由应用程序在读取Value后，自行判断内嵌的expireAt时间戳是否已过，再决定是否触发异步的缓存重建。

这个设计的妙处在于，它从根本上瓦解了“所有请求在同一毫秒发现Key消失”的同步性，天然实现了请求的“削峰填谷”。

当然，有几个细节必须敲黑板：

互斥锁是标配：必须配合类似SET key value NX PX 5000这样的分布式锁，防止多个线程同时判断过期后，重复进行数据库回源查询。
时间戳用绝对的：expireAt建议使用毫秒级的绝对时间戳，而不是相对的秒数。这样可以避免因服务器时钟漂移或服务重启带来的时间误判。
更新要原子化：更新缓存时，必须原子性地替换整个Value（包含新的expireAt），切忌只更新数据部分而忘了过期时间。

一个安全的逻辑过期读取流程（Ja va + Jedis 示例）

这里的核心，不在于代码怎么写，而在于哪几个环节一旦缺失保护就必然出问题：

第一步，解析与判断：从Redis GET到值后，务必解析JSON并检查expireAt < System.currentTimeMillis()。别忘了前置的null判断。
第二步，竞争与降级：若数据已逻辑过期，尝试用SET lock_key random_value NX PX 30000争抢锁。抢锁失败的线程，应直接返回旧的缓存数据（允许短暂的数据延迟），这是一种有效的降级策略。只有抢锁成功的线程，才负责查询数据库并更新缓存。
第三步，重建与更新：写入新缓存时，expireAt应设置为“当前时间 + 业务期望的缓存时长”（例如10分钟），切勿图省事复用旧的过期时间。
第四步，锁的释放：务必通过执行Lua脚本（EVAL）来释放锁，并在脚本中校验random_value是否匹配。这是防止误删其他线程锁的关键，否则会引发锁安全机制的彻底崩溃。

// 伪代码关键片段
String cacheJson = jedis.get("item:1001");
if (cacheJson != null) {
    CacheData data = parse(cacheJson);
    if (data.expireAt > System.currentTimeMillis()) {
        return data.data;
    }
}
// 逻辑过期，尝试加锁重建
String lockKey = "lock:item:1001";
String requestId = UUID.randomUUID().toString();
if ("OK".equals(jedis.set(lockKey, requestId, "NX", "PX", 30000))) {
    try {
        Object dbResult = loadFromDb(1001);
        String newJson = buildCacheJson(dbResult, 10*60*1000); // 新 expireAt
        jedis.set("item:1001", newJson);
    } finally {
        unlock(lockKey, requestId); // 用 Lua 校验再 del
    }
}
return getFromCacheOrOldValue(); // 返回旧值或重试

MySQL 侧需要配合做的三件事

别以为光靠Redis的逻辑过期就万事大吉。如果MySQL层面没有做好配合，慢查询甚至死锁依然会让你措手不及。

查询必须高效：所有被缓存的查询，务必使用覆盖索引，严禁使用SELECT *。否则，在高并发回源时，大量的二级索引回表操作极易成为性能瓶颈。
锁的使用要克制：对于缓存重建所用的SQL，加FOR UPDATE行锁必须慎之又慎——除非业务场景要求强一致性。在大多数读多写少的缓存场景下，使用默认隔离级别的快照读往往就够了，盲目加锁可能引发间隙锁，阻塞其他正常查询。
监控不能少：给缓存Key对应的核心业务表加上监控。重点关注Rows_examined（扫描行数）指标，如果该指标在缓存失效后突然飙升，大概率是回源SQL没有命中预期索引，需要立即介入优化。

说到底，逻辑过期方案真正的难点，往往不在于代码的实现。而在于一系列工程决策：哪些Key值得用逻辑过期？expireAt设置多长才合理？锁的超时时间如何与缓存重建耗时匹配？这些问题，没有放之四海而皆准的模板，只能依靠线上的压力测试、慢查询日志的持续分析和业务场景的反复打磨，才能找到最优解。

来源:https://www.php.cn/faq/2315453.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：MongoDB GridFS如何防止文件孤儿块产生_确保fs.files与fs.chunks原子性操作下一篇：SQL如何统计分组内不重复值的占比_结合COUNT DISTINCT计算

相关攻略

业界动态

MySQL索引优化实战：从原理到高效调优的完整指南

之前遇到一个典型的性能问题：一个订单查询接口，平均响应时间达到了3秒，P99响应时间甚至超过10秒。用户投诉不断，老板也天天催着解决。排查后发现，一张500万数据的订单表，查询条件是WHERE user_id = ? AND status = ? AND create_time > ?，但表上只有一

热心网友

05.21

业界动态

MySQL主从复制异常排查与常见原因解析

今天处理了一个典型的主从复制中断案例，SQL线程报错1032。遇到这种情况，先别急着跳过事务——这很可能是MySQL 8 0并行复制与无主键表共同埋下的一个“暗雷”。下面咱们就顺着这条线索，从Binlog机制到Hash冲突，把这个问题彻底讲清楚。主从复制异常是运维和面试中的常客，而触发异常的场景五

热心网友

05.21

业界动态

MySQL 8.0从库报错MY-010956原因分析与修复方法

在维护MySQL 8 0主从复制架构时，你是否也曾在从库的错误日志里，被两条反复横跳的警告信息刷屏？没错，就是那个“Invalid replication timestamps”和紧随其后的“returned to normal values”。这不仅仅是日志噪音，更是一个明确的信号：你的服务器时间

热心网友

05.21