Feed 三级缓存架构详解：分层设计、缓存一致性与高性能实战

[一、Feed 三级缓存分层架构设计](#一、Feed 三级缓存分层架构设计)

[四、分片与 Single-Flight 单飞防击穿优化](#四、分片与 Single-Flight 单飞防击穿优化)

前言

信息流 Feed 是社交、内容社区类产品的核心载体，承载首页公共信息流与个人知文列表两大核心场景。业务面临读延迟高、数据库压力大、缓存数据不一致 三大痛点。本文详解 Feed三级缓存整体架构，结合分片、双删、聚合桶、SDS、位图、single-flight 单飞机制，拆解原理与落地流程，实现低延迟、高缓存命中、秒级最终一致的 Feed 架构设计。

一、Feed 三级缓存分层架构设计

Feed 三级缓存核心思想是按访问速度、成本从快到慢拆分三层 ，读取遵循L2→L1→L0顺序，回源写回则从下往上回填，最大化拦截数据库请求。

L2 本地内存缓存：作为第一层热页缓存，部署在应用本地内存。访问无需走网络，直接返回完整页面数据，速度最快、无网络开销，是热点页面最优载体。即便下游 Redis、数据库故障，也可依靠本地旧数据兜底可用。

L1 Redis 页面骨架缓存 ：仅存储页面 ID 列表、分页元数据、hasMore字段。 hasMore 为布尔类型，标识是否还有下一页更多数据。L1 不存具体内容详情，只保留页面结构，命中后只需拼装数据，大幅减少缓存占用空间。

L0 Redis 条目碎片缓存 ：存储单条内容的碎片化数据，分为条目碎片 和计数碎片两类。条目碎片包含文章 ID、标题、封面、作者、标签等基础信息；计数碎片单独存储点赞数、收藏数等统计指标。拆分设计可实现按需加载、局部更新，避免全量缓存失效。

整体读流程极简：优先命中 L2 直接返回；L2 缺失查 L1 拿骨架，再批量拉 L0 碎片拼装；L1 全部未命中才回源数据库，同时异步回填各级缓存，极少请求穿透到 DB。

二、缓存拼装、分页与个性化覆盖机制

Feed 采用骨架 + 碎片拼装模式，配合分页结构与个性化用户态隔离，兼顾性能与用户体验。

分页核心载体为FeedPageResponse结构体，包含条目列表、页码、页大小、hasMore 四大核心字段，支撑无限下拉分页逻辑。

复制代码

// Java Feed分页响应实体
public record FeedPageResponse(
    List<FeedItemResponse> items,  // 条目列表
    int page,                      // 当前页码
    int size,                      // 每页条数
    Boolean hasMore                // 是否还有更多数据
){}

读取拼装流程分为三步：

L2 命中：直接返回完整分页响应，无额外拼装开销；
L2 未命中：从 L1 获取 ID 列表与分页标识，按 ID 批量查询 L0 条目碎片、计数碎片，缺失碎片做最小化补全；
回源兜底：L1 未命中时单次查询数据库页面数据，批量拉取计数，并行回填 L0、L1、L2 三级缓存。

为避免个性化状态污染公共缓存 ，用户是否点赞、收藏等个人态不写入公共缓存。采用Redis 位图 Bitmap存储用户行为状态，以二进制 0/1 标记是否操作。按用户 ID 映射位图偏移位，极致节省存储空间，查询性能极高。仅在接口返回前，实时查询位图在内存中叠加用户态，不污染全局缓存。

三、缓存失效策略与秒级最终一致设计

内容发布、置顶、可见性变更时，需驱动缓存失效，采用双删模式、前缀键隔离、聚合桶 + SDS 计数保障一致性。

公共 Feed 采用双删缓存机制：先删除缓存键，延迟几十毫秒执行二次删除。解决并发场景下，线程 A 删缓存后，线程 B 回源查库写入旧缓存的问题，等待数据库事务完成后二次清理，避免短暂数据不一致。

个人我的 Feed 采用前缀键 隔离缓存，以feed:mine:用户ID:分页参数为 Key 前缀。按用户维度独立缓存、定向清理，个人列表变更可及时失效，互不干扰。

计数统计采用聚合桶 + SDS 固定结构 实现秒级最终一致。聚合桶基于 Redis Hash 结构，临时累积点赞、收藏增量事件，无需每次行为直接修改计数，大幅降低 Redis 频繁读写压力。定时任务批量将聚合桶增量数据，折叠刷写到SDS 结构化二进制字符串。SDS 基于 Redis String 实现，固定 5 个指标分段，每个指标占 4 字节二进制存储，紧凑省空间、解析高效。

数据时序：用户行为先写入聚合桶，页面读取暂读旧 SDS 值，定时任务秒级刷新后，前端即可加载最新计数，实现业务可接受的秒级最终一致。

四、分片与 Single-Flight 单飞防击穿优化

为解决大列表、高并发回源打垮数据库问题，引入数据分片 与Single-Flight 单飞机制。

分片本质是将超大 Feed 列表、位图数据切分成多个小块，独立存储、独立失效。避免单缓存 Key 体积过大、热度过高，同时降低缓存失效时一次性批量击穿风险，分散访问压力。

Single-Flight 单飞核心是合并同 key 并发回源请求。大量并发同时未命中缓存时，仅选举一个「领飞者」请求数据库，其余请求阻塞等待结果。领飞者查询完成后写入缓存，再统一唤醒所有等待请求共享结果。

百级并发请求只需一次 DB 查询，大幅降低数据库连接与查询压力。区别于普通加锁，单飞不阻塞非同 key 请求，只合并重复回源场景，兼顾并发性能与防缓存击穿能力。

结语

本文完整拆解了 Feed三级缓存的分层设计、读写流程、分页拼装、缓存失效、计数最终一致、位图个性化隔离及 Single-Flight 防击穿全链路核心知识点。通过 L2 本地内存、L1 页面骨架、L0 碎片存储的分层思想，配合双删、前缀键、聚合桶 SDS、位图、单飞机制，有效降低接口延迟、削减数据库压力，同时保证秒级数据一致性。该架构适用于短视频、社区资讯、社交动态等各类 Feed 信息流场景，后续可进阶学习缓存冷热淘汰策略、缓存雪崩防护、分片扩容落地等优化方案。