从原理到实战的完整指南
目录导读
- 缓存数据为何会“过期”？ 理解缓存的生存周期与失效机制
- 主动清理 vs 被动清理：哪种更适合你的系统？ 对比两种策略的优劣
- 脚本编写前的准备工作 数据库、文件系统与内存缓存的差异
- 实战案例：五步编写高效清理脚本 包含Shell、Python与Redis示例
- 常见问题与避坑指南 性能影响、误删恢复与定时调度
- 问答环节 解答你可能遇到的三个核心问题
缓存数据为何会“过期”？
缓存是为了提升系统响应速度而存在的临时数据存储，但数据源（比如数据库）会不断更新，如果缓存永远不更新，用户就会读到“陈旧”的数据，几乎所有缓存系统都支持设置TTL（生存时间）——例如Redis的EXPIRE命令、Memcached的过期时间、浏览器缓存中的max-age头部。
实际情况中,过期数据并不一定会被立即清除。
- Redis默认的惰性删除：仅在访问键时检查是否过期,未访问的过期键可能持续占用内存。
- 文件缓存中,用户手动下载的临时文件可能永远无人清理。
- 数据库查询缓存的碎片长期堆积。
这就需要一个主动清理脚本，定期扫描并删除那些“活过保质期”的数据。
主动清理 vs 被动清理：哪种更适合你的系统？
| 维度 | 主动清理 | 被动清理 |
|---|---|---|
| 触发时机 | 由定时任务（如cron）手动执行 | 在读取缓存时自动检查并删除 |
| 内存控制 | 更可控，防止缓存无限膨胀 | 可能因长期不访问导致内存泄漏 |
| 性能影响 | 集中在脚本执行时段 | 分散在每次请求中，无尖峰负载 |
| 适用场景 | 低延迟要求不高的后台任务 | 高频访问、实时性要求高的系统 |
对大多数Web应用，建议被动清理为主，主动清理为辅，例如Redis的maxmemory-policy设置为allkeys-lru自动淘汰,同时每周运行一次主动清理脚本。
脚本编写前的准备工作
确定缓存存储类型
- 内存型（Redis/Memcached）：通过API扫描键并批量删除。
- 文件型（tmp目录/CDN缓存）：遍历文件系统,检查文件修改时间。
- 数据库型（MySQL查询缓存/物化视图）：执行SQL语句删除过期记录。
确定过期判断依据
- 显式TTL：如Redis键的
TTL值。 - 隐式时间戳：文件
mtime或数据库中expires_at字段。 - 组合条件：缓存A于2023年生成，且
version小于2”。
制定安全策略
- 测试环境先行：先在staging环境运行脚本。
- 使用
--dry-run模式：只打印将要删除的内容,不实际执行。 - 设置删除上限：单次清理不超过1000条记录,防止长时间锁表。
实战案例：五步编写高效清理脚本
案例1：清理Redis过期键（Python）
import redis
import time
def clean_expired_redis(host='localhost', port=6379, db=0, batch_size=100):
r = redis.Redis(host=host, port=port, db=db)
cursor = '0'
total_deleted = 0
while cursor != 0:
cursor, keys = r.scan(cursor=cursor, count=batch_size)
for key in keys:
ttl = r.ttl(key)
if ttl == -2: # 键不存在
continue
elif ttl == -1: # 永不过期（需根据业务判断）
if should_force_expire(key): # 自定义逻辑
r.delete(key)
total_deleted += 1
elif ttl == 0 or ttl == -2: # 已过期
r.delete(key)
total_deleted += 1
# 避免CPU过载
time.sleep(0.1)
print(f"共删除 {total_deleted} 个过期键")
案例2：清理N天前生成的临时文件（Shell）
#!/bin/bash
# 删除/tmp目录下7天前的文件
CLEAN_DIR="/tmp/cache"
EXPIRY_DAYS=7
DRY_RUN=false
# 安全选项：如果存在--dry-run参数则不实际删除
if [[ "$1" == "--dry-run" ]]; then
DRY_RUN=true
fi
if $DRY_RUN; then
echo "模拟运行：将删除以下文件"
find "$CLEAN_DIR" -type f -mtime +$EXPIRY_DAYS -print
else
find "$CLEAN_DIR" -type f -mtime +$EXPIRY_DAYS -delete
echo "清理完成，已删除超过${EXPIRY_DAYS}天的文件"
fi
案例3：清理MySQL中的过期缓存记录（SQL脚本）
DELIMITER //
CREATE PROCEDURE CleanExpiredCache()
BEGIN
DECLARE deleted_count INT DEFAULT 0;
DELETE FROM cache_table
WHERE expires_at < NOW()
ORDER BY id
LIMIT 1000; -- 分批删除防止锁等待
SET deleted_count = ROW_COUNT();
SELECT CONCAT('已删除 ', deleted_count, ' 条过期缓存') AS result;
-- 可选：如果需要重复执行直到全部清理
WHILE deleted_count > 0 DO
DELETE FROM cache_table
WHERE expires_at < NOW()
ORDER BY id
LIMIT 1000;
SET deleted_count = ROW_COUNT();
END WHILE;
END//
DELIMITER ;
-- 调用存储过程
CALL CleanExpiredCache();
常见问题与避坑指南
问题1：清理脚本会不会影响正常业务？
- 解决方案：添加
--throttle参数，控制每秒删除数量，例如Python脚本中插入time.sleep(0.2)。
问题2：误删了重要缓存数据怎么办？
- 解决方案：
- 使用延迟删除：先移动到
_trash目录,72小时后真正删除。 - 日志记录：删除前打印
DELETE ttl={ttl} key={key}。 - 数据库事务：对于SQL脚本，使用
BEGIN和ROLLBACK测试。
- 使用延迟删除：先移动到
问题3：如何设置合理的清理周期？
- 原则：清理周期 = 缓存TTL的50%~70%，例如缓存TTL为24小时,则每12小时清理一次。
- 持续监控：使用Prometheus收集缓存命中率，当命中率低于80%时触发紧急清理。
问答环节
Q1：我的Redis已经设置了maxmemory-policy allkeys-lru，还需要主动清理吗？
A1：需要，LRU（最近最少使用）算法只会在内存达到maxmemory上限时才开始淘汰，如果你的Redis内存使用率仅有60%，过期键会一直存在，导致“缓存污染”——查询时可能返回过期数据，主动清理脚本可以提前释放内存,并保证数据新鲜度。
Q2：清理文件缓存时，如何避免误删正在使用的文件？
A2：采用引用计数或锁机制。
- 在文件创建时生成
.lock文件,清理脚本跳过有锁的文件。 - 使用
lsof命令检查文件是否被进程占用（Shell示例）：find /tmp -type f -mtime +7 | while read f; do if ! lsof "$f" > /dev/null 2>&1; then rm "$f" fi done
Q3：如果缓存数据量极大（数千万个键），扫描会不会阻塞Redis？
A3：务必使用SCAN而非KEYS命令。SCAN是游标式迭代，每次返回少量键（默认10个），不会阻塞主线程，你可以通过调整count参数（如1000）来平衡扫描速度与redis性能，建议在Redis节点从库上运行清理脚本。
编写主动清理过期缓存脚本的核心是分步执行、安全优先、配合监控，根据你的缓存类型选择对应的扫描删除策略，并通过--dry-run、分批删除、记录日志等手段降低风险，将脚本接入cron或Kubernetes CronJob,让清理工作自动化运转。
