你们有分页那么你分页的结果是怎么存入到redis中的

首次来源：明略科技 2021 一面

原题

你们有分页,那么你分页的结果是怎么存入到redis中的?

完整讲解（权威版）

最后更新：2026-10-30 · 基于第 1 次作答

L1 · 30 秒速记

结论：分页缓存要看数据规模与变更频率——小数据全量缓存、大数据只缓存热页，且必须处理一致性。 关键词：全量缓存 · 首页缓存 · 分页 key · 延迟双删 · 缓存穿透 边界：低频变更可全量；高频变更只缓存首页或短 TTL。

L2 · 核心讲解

核心考点定位：面试官想听"缓存的粒度 + key 设计 + 一致性"，而不是"把结果放 Redis"一句话。

机制链（≥3 环）：

1. 粒度判断 → 数据量小且变更低频（如百人商户列表）→ 全量缓存，分页/排序在应用层做。
2. 热页缓存 → 数据量大且高频变更（如订单）→ 只缓存首页（第一页访问频率最高），后续页直接查库。
3. 一致性 → 缓存与 DB 双写，用延迟双删或版本号；更新时先删缓存，防旧数据被读。
4. key 设计 → 分页缓存 key 必须能唯一定位到"页 + 筛选条件"，读时反序列化，写时按 key 覆盖。
5. 穿透防护 → 查空结果缓存空值或布隆过滤器，防高频请求穿透到 DB 打挂库。

证据锚点：

• key 设计：分页缓存 key 常为 page:{pageNo}:{pageSize} 或加筛选条件 hash。
• 全量缓存：适合小数据 + 低频变更，一次加载常驻，省多次 DB 查询。
• 首页缓存：大数据只缓存第一页，命中率高、缓存量可控；后续页低频访问不入缓存。
• 延迟双删：先删缓存 → 更新 DB → 延迟 N 秒再删，防并发读旧值回填。
• 缓存穿透：查空结果也要缓存空值或布隆过滤器，防高频请求穿透到 DB。
• TTL：缓存过期时间按数据变更频率设，高频变更用短 TTL 自愈。
• 布隆过滤器：判断 key 是否可能存在，不存在直接拦截，减少空查询。
• 版本号：缓存带版本字段，更新时比对版本，旧版本不覆盖新数据。
• 一致性：先删缓存再更新 DB，避免"先更新 DB 后删缓存"的旧值回填窗口。
• SET/GET：Redis 写缓存与读缓存命令，配合过期时间使用。
• JSON 序列化：分页结果以 JSON 字符串存储，读时反序列化恢复对象列表。
• pageSize：分页大小决定 key 粒度，过大 key 命中率低、过小 key 爆炸。
• 2 秒：延迟双删的常见延迟窗口值，覆盖并发读回填窗口。

对比与权衡：

常见误区：

1. 错误：分页结果直接 List 塞 Redis → 正确：按 key（page/size/条件）存 JSON，读时反序列化 → 为什么：需定位到具体页。
2. 错误：只加缓存不管一致性 → 正确：延迟双删 / 版本号 → 为什么：缓存与 DB 不一致是最大坑。
3. 错误：所有页都缓存 → 正确：只缓存热页（首页），翻页低频 → 为什么：避免缓存资源浪费。
4. 错误：缓存过期时间越长越好 → 正确：按变更频率设 TTL，高频变更短 TTL → 为什么：防脏数据长期滞留。
5. 错误：空结果不缓存 → 正确：空值缓存或布隆过滤器 → 为什么：防缓存穿透打挂 DB。

适用边界：如果数据每天高频变动，全量缓存会频繁失效，此时短 TTL 或只缓存首页更合适；排序/搜索复杂的查询不适合简单 key 缓存，要考虑结果集失效问题。

延伸追问（≥3）

1. 分页缓存 key 怎么设计？

• 要点：page:{pageNo}:{pageSize} + 筛选条件，条件变化要拆 key 或做条件 hash。
• 追问落点：key 爆炸问题（条件组合多）怎么控制。

1. 缓存和数据库一致性能怎么保证？

• 要点：先删缓存 → 更新 DB → 延迟双删；或版本号比对。
• 追问落点：为什么不能先更新 DB 再删缓存（旧值回填）。

1. 首页缓存命中率怎么保证？

• 要点：第一页访问最高，缓存首页 + 短 TTL；非首页查库。
• 追问落点：缓存容量与命中率权衡。

面试者参考回答（400–700 字）

【结论】 面试官您好，分页结果存 Redis 的关键不是"存进去"，而是"粒度、key、一致性"三个设计决策。

【三点】 第一，看数据规模与变更频率。我们之前有一类是商户信息，数据量小（一两百人）、变更频率低、基本由后台管理更新，就全量缓存到 Redis，分页、排序、搜索都在应用层代码里做，充分利用缓存；因为更新少，刷新缓存成本低。第二，如果是订单这种数据量大、高频变动的数据，就不适合全量缓存，我们只缓存第一页（首页访问频率最高），后续页直接查库——翻页的人少，没必要浪费缓存资源。第三，无论哪种，key 设计要能定位到具体页（比如 page:1:20，带上筛选条件），并且要处理一致性：更新时先删缓存再更新 DB，延迟一段时间再删一次（延迟双删），防止并发读把旧值回填缓存；如果查出来是空，缓存空值或布隆过滤器防缓存穿透。

【边界】 当然，这套策略不是固定——如果数据高频变动，全量缓存会频繁失效，不如短 TTL 或只缓存首页；如果查询排序条件组合非常多，简单 key 缓存会 key 爆炸，要考虑按条件 hash 或干脆走 DB + 索引。核心是判断"数据变更频率"和"缓存容量成本"，别为了缓存而缓存。

面试记录 2026-10-30（第 1 次）

题目：你们有分页那么你分页的结果是怎么存入到redis中的

难度：medium

标签：real-interview, computer/os, company/明略科技

评分：⭐⭐⭐☆☆（3/5）

我的回答

这个分页看几种情况，一种是数据量大的，一种是数据量小的。我那个最近的那个分页是把整体数据全都放到 Redis 中，然后读取出来，根据实际情况再去算分页和算外部的业务逻辑，这样可以更好的利用缓存。因为我算的那个数据是 B 商用户的信息，这些信息它的变动是不高的，更新频率比较低，而且更新的话基本上也是后台管理系统去更新，这时候我会刷新缓存。然后前置的这个数据缓存分页，由于它是对外的直接的一个入口，承受比较高的并发，它使用的方式是数据全量在 Redis 中。当然，这个数据量没那么大，它整个的 B 商体系也就是一两百人;这些数据全量的在 Redis 缓存中，通过各种逻辑去判定这个人可见的数据，然后去查询、搜索跟排序，都是在项目中通过代码实现的，并不是走数据库实现的。我之前的话，分页存储的话，基本上就主要是打主分页，主页第一页会做缓存，后边的页不会做缓存。因为只有第一页的展现频率会比较高，并且缓存的时间其实都很短。因为这方面需要考虑业务场景，你要判断你的数据时间存储长短。如果是像刚刚那种长时间，B 商那种信息长时间存储的话，没什么问题，可以一直用。如果是像订单信息这种短时间存储的，或者是有时间周期的，首页可能会存储，后面翻页的人并不多，并不需要浪费缓存资源去存储它。

点评

优点：区分数据量大小与变更频率（低频全量缓存 vs 高频只缓存首页）；考虑缓存时长与业务场景；工程取舍思维好。

不足：漏了分页 key 设计（page:no:size）、缓存一致性（延迟双删/版本号）、TTL 设置、缓存穿透防护。

补充：分页缓存要讲"粒度 + key + 一致性"三件事，一致性（延迟双删）是面试官最想听的技术细节。

完整讲解见上方「完整讲解（权威版）」