热点问题根因：为什么全表扫描会导致Redis缓存雪崩与热点Key
在报表导出服务中，当PostgreSQL执行全表扫描时，大量数据被一次性加载到内存并逐行处理。这种看似常规的数据库操作，却往往是引发Redis缓存雪崩与热点Key的导火索。理解其背后的因果链条，是设计有效索引方案的前提。
全表扫描的连锁反应路径
全表扫描并非孤立事件，它会通过以下路径逐级传导，最终冲击Redis集群：
- 大量数据读取：查询条件无法使用索引，PostgreSQL顺序扫描整个表，读取数百万甚至上千万行数据。
- 逐行业务处理：应用层对每一行执行计算、聚合、格式化等操作，产生大量中间结果。
- 缓存查询风暴：业务逻辑中频繁查询Redis获取配置、字典、权限等辅助数据，每次全表扫描触发海量Redis请求。
- 缓存失效与重建：大量Key同时过期或被逐出，导致请求穿透到后端数据库，形成雪崩。
- 热点Key集中：某些高频使用的配置项或字典数据被所有查询线程同时访问，成为热点Key。
核心结论：全表扫描本身不直接操作Redis，但它放大了应用层对Redis的请求量级和并发度，将原本分散的缓存访问模式转变为集中式爆发。
缓存雪崩的触发机制
缓存雪崩是指大量缓存Key在同一时间段内集中失效，导致请求直接打到数据库。全表扫描通过以下方式加速雪崩：
| 触发因素 | 全表扫描下的表现 | 雪崩风险等级 |
|---|---|---|
| Key过期时间集中 | 报表导出任务批量查询，导致大量辅助Key同时被访问并触发过期 | 高 |
| 内存逐出策略 | 全表扫描产生的临时数据占用大量Redis内存，触发LRU逐出 | 中高 |
| 缓存预热失败 | 首次全表扫描时缓存未命中，后续请求持续穿透 | 高 |
| 并发请求叠加 | 多个报表导出线程同时执行全表扫描，Redis请求量呈倍数增长 | 极高 |
典型场景：某报表服务在每日凌晨执行全量数据导出，PostgreSQL全表扫描读取500万行订单数据。每行处理过程中查询Redis获取用户等级配置（Key: user_level_config）、商品分类映射（Key: category_map）、地区编码表（Key: region_code）。这三个Key被所有500万次循环访问，且过期时间均设置为凌晨2:00，导致雪崩。
热点Key的形成原理
热点Key是指Redis中某个Key的访问频率远超其他Key，导致单节点CPU、带宽、内存出现瓶颈。全表扫描通过以下模式制造热点：
- 循环引用模式：全表扫描的循环体内反复查询同一个Redis Key，例如每次迭代都读取
system_config:export_limit。 - 全局共享数据：所有报表导出任务共享相同的字典表、配置表，这些数据在Redis中对应少量Key。
- 无差别缓存查询：业务代码未对高频查询做本地缓存，每次全表扫描都直接请求Redis。
// 伪代码：全表扫描中的热点Key模式
for each row in full_table_scan:
// 每次循环都查询同一个Redis Key
config = redis.get("system_config:export_limit")
if config is None:
config = load_from_db("system_config")
redis.setex("system_config:export_limit", 3600, config)
// 使用config处理当前行
process_row(row, config)
上述代码中，system_config:export_limit在500万次循环中被访问500万次，成为绝对热点。即使Redis单节点QPS达到10万，也需要50秒才能处理完，期间其他请求被阻塞。
全表扫描 vs 索引扫描：Redis请求量对比
| 对比维度 | 全表扫描 | 索引扫描 |
|---|---|---|
| 扫描行数 | 500万行 | 1000行（通过索引过滤） |
| Redis请求次数 | 500万次（每行1次） | 1000次 |
| 热点Key出现概率 | 极高 | 低 |
| 雪崩触发风险 | 高 | 低 |
| Redis网络带宽消耗 | ~500MB（假设每次1KB） | ~1MB |
关键指标：全表扫描将Redis请求量从
O(log N)级别放大到O(N)级别。当N达到百万级时，即使每个Redis操作仅耗时0.1ms，总耗时也将超过100秒，远超正常响应时间。
根因总结：全表扫描作为放大器
全表扫描本身不是Redis问题的直接原因，但它是一个请求放大器：
- 放大倍数 = 全表扫描行数 / 索引扫描行数，通常为1000~10000倍。
- 放大对象：Redis查询次数、网络连接数、CPU占用、内存占用。
- 放大后果：缓存雪崩（大量Key同时失效）、热点Key（单个Key被高频访问）、Redis节点过载。