1.热点数据处理。场景流量明星发送微博信息一分钟内涌入5000万人。首先我们要对数据的流动进行充分的理解用户点击微博点开热点信息点赞评论转发客户端传入数据库进行缓存缓存拦截大量重复。结合微服务就还要加一个网关。考察1.能不能对并发流量问题拆解多个层次。2.知不知道对核心业务的取舍3.理解高并发的过程分析热点流量特点是来的快去的也快大量的读写操作并发。核心业务点赞评论。解决组合:所有操作都要围绕不要让数据库崩掉让少数的数据进入数据库大量的数据被拦截围绕这个核心可以得出。拆分四个层次。第一层多级缓存抗流量。事件特点是读多写少1.redis缓存进行抗读大量的数据需要在redis层被拦截。最外层cdn静态资源比如图片视频推到边缘节点用户刷微博用不上服务器。第二层本地缓存将热点数据放在内存里面连redis都不用差。第三层redis 保证高可用这是又涉及redis的穿透雪崩击穿持久化【redis】缓存穿透 缓存击穿 缓存雪崩-CSDN博客 链接失效去主页找。第二层当流量太大缓存也抗不住就要进行服务降级操作。保证核心业务边缘业务先放一放。如刷微博写微博评论是核心业务个性推荐是边缘业务。读可以降级为过期数据点赞延迟更新评论去显示部分评论写可以异步写入使用消息队列异步处理。第三层限流保护两个核心算法令牌桶算法漏桶算法。为什么限流一个核心保证系统不被大量数据冲爆。假设有五万张票但是你不能让50万人抢所以得限流让他们排队。限流可以分层如果有网关层网关层可以进行分流单台服务器每秒最多10万请求超出返回服务层繁忙应用层利用算法对每个接口进行单独限流比如发微博接口每秒一万点赞每秒五万数据采用连接池限制最多启用1000个连接保护数据库安全。第四层增加硬实力动态扩容。服务器进行扩容但是要区分情况如热点数据来的快去的也快进行扩容就太浪费资源了。使用云原能力kubernetes自动伸缩Docker镜像。但是记住阔再多数据库扛不住在多也没有日活高像微信qq等数据库一定是分库分表的按用户id哈希将数据打散到库里面。最后还可以加消息队列削峰争对大量猛增的数据一会突然下降的数据使用kafka削峰高吞吐用户发微博点赞评论仍进队列后端慢慢处理。总结缓存扛读降级保护核心限流防打死数据库扩容补资源队列削峰填谷2.发红包场景多层防御架构从外到内层层兜底第一层缓存层核心防护第一道主力防线1. 分布式互斥锁串行重建缓存禁止并发查库核心思路缓存失效时只允许一个线程去 DB 查数据并重建缓存其余线程等待 / 重试。落地实现Redisson分布式锁Redis 官方推荐自带锁续期、防死锁优化自旋重试 超时控制避免大量线程阻塞占用连接适用场景强一致性要求、热点 Key 更新频率低的场景如商品详情2. 逻辑过期永不主动删 Key后台异步刷新核心思路缓存 Value 里存过期时间戳业务线程只判断时间戳是否过期不阻塞过期后立即返回旧值同时用异步线程去 DB 拉新数据更新缓存。优点无锁、无阻塞、吞吐量拉满完全不打崩 DB缺点短时间会读到旧数据最终一致性适用场景高并发秒杀、热搜、榜单等允许短暂脏读的场景3. 热点 Key 永久不过期 主动异步刷新核心思路标记热点 Key设置TTL-1永不过期后台定时任务 / 消息队列异步更新缓存配合缓存预热服务启动时提前加载热点数据适用场景超级热点 Key如爆款商品、首页 Banner4. 多级缓存本地缓存兜底避免穿透到 Redis架构JVM本地缓存(Caffeine) Redis分布式缓存热点 Key 先放 Caffeine本地内存O (1) 访问比 Redis 快 10~100 倍本地缓存过期后再查 RedisRedis 过期再走锁重建关键本地缓存设置短 TTL避免数据不一致 内存溢出优势即使 Redis 宕机 / 抖动本地缓存仍能扛住流量第二层应用层流量管控第二道防线削峰填谷1. 热点 Key 自动探测与标记实时统计 QPS、访问频次自动识别热点 Key对识别出的热点 Key提前预热、永久不过期、放入本地缓存落地Redis 客户端热 Key 统计、网关层埋点、日志分析2. 接口限流 熔断降级网关 / 服务层对热点接口做单机限流 分布式限流超出阈值直接熔断返回兜底数据静态页、默认值配合 Sentinel/Hystrix自动降级防止流量压垮服务3. 请求合并 / 批处理高并发下将同一 Key 的并发请求合并只执行一次 DB 查询结果复用给所有请求落地Guava Cache、自定义合并器、消息队列攒批第三层数据库层抗压第三道防线最后兜底1. 数据库限流 读写分离读请求走从库主库只负责写入避免主库被打挂DB 层配置连接池限流、SQL 限流禁止无限制查询2. 索引优化 轻量查询热点查询必须命中主键 / 唯一索引禁止慢查询只查必要字段减少 DB IO 与 CPU 开销禁止事务 长查询避免锁等待3. 分库分表 / 冷热数据分离热点数据单独分片避免与冷数据争抢资源提升查询效率第四层架构兜底与一致性保障终极防线1. 静态兜底数据预生成静态页面 / 默认 JSON缓存击穿时直接返回兜底数据对用户无感知保证服务可用2. 缓存 DB 双写一致性避免重建缓存时出现数据不一致方案先更DB再删缓存Cache Aside Pattern异步更新通过 Canal 订阅 MySQL binlog自动同步 Redis第五层监控预警 主动治理防患于未然监控指标Redis 热 Key 数量、命中率、过期 Key 分布DB 连接数、慢查询、CPU 负载接口 QPS、熔断次数、降级比例自动预警缓存命中率低于阈值告警热点 Key 即将过期自动提醒主动扩容热点时段自动扩容 Redis / 应用节点临时提升 DB 读能力资深程序员生产级「最佳组合拳」根据业务一致性要求分两套落地方案方案 A强一致性商品详情、订单多级缓存(CaffeineRedis) Redisson分布式锁 DB读写分离 限流熔断方案 B高并发最终一致性秒杀、热搜、榜单本地缓存永久热点Key 逻辑过期 异步刷新 熔断降级 静态兜底必避坑点资深踩坑总结不要用本地锁synchronized/Lock应对集群部署会出现多节点同时查库互斥锁必须加超时时间防止线程崩溃导致死锁逻辑过期不要和强一致性业务混用避免客诉热点 Key 不要设置随机 TTL 打散会人为制造击穿禁止缓存重建时做复杂业务计算拖慢响应、占用线程一、整体流程概览核心思想缓存未命中 → 抢分布式锁 → 只允许一个线程查库更新缓存 → 其他线程等待重试 → 缓存更新后全部命中返回关键设计点双检缓存抢锁前后都查一次缓存避免重复查库锁自动续期防止查询 DB 过慢导致锁提前释放有限重试避免线程无限自旋占用资源空值缓存顺便解决缓存穿透finally 释放锁绝对防止死锁二、详细执行步骤逐行可落地假设有一个热点 Keyproduct:detail:1001步骤 1接收请求先查 Redis 缓存plaintext请求 → get(product:detail:1001)命中直接返回数据流程结束未命中进入锁逻辑步骤 2【第一次双检】再次查缓存为什么高并发下可能刚有其他线程更新完缓存你没必要再抢锁。plaintextif (cache.exist(key)) { return cache.get(key); }步骤 3尝试获取分布式锁锁 Key 建议lock:cache:product:detail:1001使用 RedissonRLock lock redisson.getLock(lockKey);加锁lock.lock(5, TimeUnit.SECONDS);5s 是锁超时时间Redisson 会自动续期watchdog 机制步骤 4【第二次双检】再次查缓存这一步极其重要可能你在等待锁的过程中其他线程已经把缓存重建好了。plaintextif (cache.exist(key)) { return cache.get(key); }步骤 5只有抢到锁 缓存仍不存在 → 查询数据库plaintextData data dbMapper.selectById(id);步骤 6将数据写回 Redis数据非空写入缓存 设置正常 TTL如 30min数据为空写入空值 / 默认值 设置短 TTL如 1min防穿透plaintextredis.set(key, data, 30, TimeUnit.MINUTES);步骤 7释放分布式锁必须放在finally里保证任何异常都能释放plaintextfinally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }步骤 8返回数据未抢到锁的线程处理逻辑线程 sleep 一小段时间如 50ms重试查缓存最多 35 次重试成功返回缓存数据重试失败返回兜底数据 / 抛出限流异常三、标准伪代码Java 风格可直接改写成业务代码java运行public ProductDetail getProductDetail(Long productId) { String cacheKey product:detail: productId; String lockKey lock:cache: cacheKey; // 1. 查缓存 ProductDetail cache redisTemplate.get(cacheKey); if (cache ! null) { return cache; } RLock lock redissonClient.getLock(lockKey); try { // 尝试加锁最多等待 1s锁持有 5sRedisson自动续期 boolean lockSuccess lock.tryLock(1, 5, TimeUnit.SECONDS); if (!lockSuccess) { // 未抢到锁短暂休眠重试 Thread.sleep(50); // 最多重试2次 for (int i 0; i 2; i) { cache redisTemplate.get(cacheKey); if (cache ! null) return cache; Thread.sleep(50); } // 重试失败返回兜底或抛异常 return getDefaultDetail(productId); } // 2. 抢到锁后【再次双检】 cache redisTemplate.get(cacheKey); if (cache ! null) { return cache; } // 3. 只有真正需要才查DB ProductDetail dbData productMapper.selectById(productId); // 4. 写回缓存空值处理 if (dbData ! null) { redisTemplate.set(cacheKey, dbData, 30, TimeUnit.MINUTES); } else { // 防穿透缓存空值短过期 redisTemplate.set(cacheKey, EMPTY_DETAIL, 1, TimeUnit.MINUTES); } return dbData; } catch (InterruptedException e) { Thread.currentThread().interrupt(); return getDefaultDetail(productId); } finally { // 必须释放锁 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }四、为什么必须这么设计资深要点1. 为什么要两次查缓存第一次过滤掉大部分并发第二次防止你等待锁期间别人已经重建好缓存避免1000 个并发同时抢锁都去查 DB2. 为什么用 Redisson 而不是手写 SETNXRedisson 自带watchdog 锁续期查询 DB 慢也不会锁超时释放可重入、防误删、防死锁手写SETNX DEL极易在异常时造成死锁3. 为什么未抢到锁要重试而不是直接报错热点 Key 重建极快毫秒级重试 23 次基本都能命中缓存用户无感知。4. 锁超时设多久合适锁等待时间1s 以内锁持有时间5sRedisson 会自动续期避免锁时间太长导致故障时阻塞太久五、极端异常场景兜底Redis 挂了→ 关闭缓存逻辑直接限流 降级走 DBDB 查询超时→ 锁自动释放下一个线程重试应用突然宕机→ Redisson 锁超时自动释放无死锁大量线程同时重试→ 配合接口限流防止雪崩六、总结最简流程口诀先查缓存未命中抢锁抢到再查避免重复查库查库写缓存空值也要存finally 释放锁重试不死锁