背景feed流投喂流主动把消息发给我们类似于朋友圈别人的消息组成了我的主页feed流与内容详情是该社区访问最多的接口面临着以下挑战- **高并发读压力**首页 Feed 与热门内容详情同一时刻可能面对数千次并发请求。- **缓存击穿Hot Key**热点内容被同时打穿缓存导致数据库瞬间过载。- **缓存穿透**查询不存在的内容每次都回源数据库。- **缓存雪崩**大量缓存同时过期流量同时回源。二级缓存架构L1Caffeine 本地缓存进程内~0 ms│ 命中 → 直接返回叠加用户态后返回│ 未命中 ↓▼L2公共 FeedRedis 片段缓存ids / item / hasMoreL2详情 / 我的发布Redis 整页 JSON 缓存~1–5 ms│ 命中 → 填充 L1返回│ 未命中 ↓▼Single-Flight 锁防击穿惊群│ 等待锁后再查 L2Double Check│ 仍未命中 ↓▼L3MySQL 数据库~10–100 ms│├── 写入 L2 Redis 缓存带随机抖动 TTL├── 写入 L1 Caffeine 缓存└── 返回叠加用户态后返回三层定位L1本地缓存存储的是完整的页面响应对象条目数组页码数量hasmore是否还有更多数据需要加载本地存储超短ttl容量有限专用于最热点keyL2redis存页面的骨架存储完整的页面数据结构如帖子详情页、Feed流页面用户无关数据 存储不包含用户个性化信息的数据如点赞/收藏状态全局共享ttl较长L1为ttl时间设置抖动防止缓存雪崩用于L1查询不到数据保护mysql直接被查询支持持久化L3mysql存储页面的所有元数据以及包括点赞收藏........计数是数据的大后方实现1.定义方法和参数处理2.生成缓存键3.从本地缓存拿数据4.如果本地缓存未查到从redis中查5.单飞锁当l1和l2都未查到时多请求打向数据库利用单飞锁防止缓存穿透SingleFlight 同一时刻对同一个 key 的请求只执行一次结果共享给所有等待者。对于多个请求只有一个请求能进去先重查L2因为第一个请求已经回源了数据库所以可以直接返回后回源数据库6.回源数据库回源数据库之后将数据重新写入两级缓存并释放锁对上面的方法补充记录热度记住record方法滑动窗口自定义hotkey探测1. 滑动窗口设计 - 窗口长度60秒可配置- 分段长度10秒可配置- 分段数量6个60/102. 数据结构 - 使用 ConcurrentHashMapString, int[] 存储每个key的计数数组- 每个key对应一个长度为6的数组每个元素代表一个10秒分段的访问次数- 使用 AtomicInteger 维护当前活跃分段的索引3. 计数机制 - 每次访问时调用 record(key) 方法- 将计数累加到当前活跃分段的位置- 采用无锁操作确保高并发下的性能4. 窗口滑动 - 每10秒执行一次 rotate() 方法- 将当前分段索引移动到下一个位置循环- 清零新的当前分段实现窗口的滑动效果热度等级与动态TTL1. 热度等级划分 - LOW窗口内访问次数≥50- MEDIUM窗口内访问次数≥200- HIGH窗口内访问次数≥5002. 动态TTL计算 - 基准TTL 热度等级对应的扩展时间- LOW20秒- MEDIUM60秒- HIGH120秒3. 使用场景 - 在Feed流访问时对每个条目调用 recordItemHotKey(item.id())- 计算该条目的热度等级- 动态延长相关缓存的TTL保护热点内容level代码的调用在ttlForPublic中记录热度滑动窗口的滑动机制Scheduled注解每10秒执行retate滑动原理 - 计算下一个分段索引 (current.get() 1) % segments- 更新当前分段指针到新位置- 清零新分段的计数为新的时间段做准备工作流程 1. 初始化 每个key对应一个长度为6的数组初始值全为02. 计数 每次访问时在当前分段位置13. 滑动 每10秒执行一次rotate将指针移动到下一个分段并清零4. 热度计算 累加所有6个分段的计数得到最近60秒的总访问次数5. 等级判断 根据总热度判断热度等级6. 动态TTL 根据热度等级计算延长的TTL时间- 时间0-10秒使用分段0计数- 时间10-20秒rotate到分段1清零分段1使用分段1计数- 时间20-30秒rotate到分段2清零分段2使用分段2计数- 以此类推60秒后回到分段0清零分段0开始新的循环这种设计能够实时反映最近60秒的访问热度并且随着时间推移自动衰减旧数据的影响。本地缓存和滑动窗口的基础配置