解析Redis分布式缓存清理的核心方案，从基础TTL设置到Lua脚本、Stream流处理等高级技巧

一、当缓存成为甜蜜的负担

在电商大促的午夜，我们的系统突然出现数据库连接池耗尽告警。排查发现某商品详情页的缓存键设计存在批量失效问题，300万条缓存数据在凌晨2点同时过期，瞬间的缓存雪崩导致数据库压力激增。这个事件让我深刻认识到：分布式缓存的清理不是简单的删除操作，而是需要精密设计的系统工程。

二、Redis分布式缓存清理技术全景图

2.1 基础武器：TTL时间魔法

# Python示例（Redis-py技术栈）
import redis

r = redis.Redis(host='redis-cluster.prod', port=6379, db=0)

# 设置带过期时间的缓存
r.set("product:12345:detail", "{...}", ex=3600)  # ex参数设置秒级过期时间

# 查询剩余生存时间
ttl = r.ttl("product:12345:detail")
print(f"缓存将在{ttl}秒后自动清除")

这是最基础的缓存清理方式，适合明确知道数据生命周期的场景。但要注意时钟同步问题——当集群节点间存在时间偏差时，可能导致过期时间不一致。

2.2 精准打击：主动清理策略

# 批量删除匹配模式的键（生产环境慎用！）
def batch_delete(prefix):
    cursor = 0
    while True:
        cursor, keys = r.scan(cursor, match=f"{prefix}:*", count=1000)
        if keys:
            r.delete(*keys)
        if cursor == 0:
            break

# 定时任务示例（凌晨执行）
schedule.every().day.at("03:00").do(batch_delete, "product:temp")

SCAN命令相比KEYS更安全，但要注意：

1. count参数控制遍历粒度
2. 大集群删除操作建议分片执行
3. 避免在业务高峰期执行

2.3 原子操作：Lua脚本的威力

-- 删除三天前修改的特定前缀键
local keys = redis.call('SCAN', 0, 'MATCH', ARGV[1], 'COUNT', 1000)
local deleted = 0
for _, key in ipairs(keys[2]) do
    local last_modified = redis.call('OBJECT', 'IDLETIME', key)
    if last_modified > 259200 then  -- 259200秒=3天
        redis.call('DEL', key)
        deleted = deleted + 1
    end
end
return deleted

在Redis集群中执行时需要使用hash tag确保脚本在单个节点执行：

r.eval（lua_script, 1, "{product}:*")  # 花括号保证相同slot分布

三、进阶实战方案

3.1 流式处理方案（Redis Streams）

# 创建清理任务流
r.xadd("cache_clean_stream", {"action": "delete", "pattern": "session:inactive:*"})

# 消费者组处理
while True:
    messages = r.xreadgroup("group1", "consumer1", {"cache_clean_stream": ">"}, count=10)
    for msg in messages:
        process_message(msg)
    time.sleep(1)

这种方案特别适合需要审计清理记录的金融场景，但要注意消费者组的消息确认机制。

3.2 内存淘汰策略

当内存达到maxmemory时，Redis提供多种淘汰策略：

# redis.conf配置示例
maxmemory 16gb
maxmemory-policy allkeys-lru

不同策略对比：

• volatile-lru：只淘汰设置过期时间的键
• allkeys-lfu：基于访问频率淘汰
• volatile-ttl：优先淘汰剩余时间短的键

3.3 冷热数据分离架构

# 使用不同的Redis实例
hot_redis = redis.Redis(host='hot-node', port=6380)
cold_redis = redis.Redis(host='cold-node', port=6381)

# 数据迁移逻辑
def data_migration(key):
    value = hot_redis.get(key)
    if value:
        cold_redis.setex(key, 604800, value)  # 冷数据存储7天
        hot_redis.delete(key)

通过多级缓存架构，可以将清理操作转化为数据降级操作，降低对业务的影响。

四、避坑指南与最佳实践

4.1 缓存雪崩防御方案

采用分层过期策略：

# 设置基础过期时间
base_ttl = 3600
# 增加随机扰动（300秒=5分钟）
random_ttl = random.randint(0, 300)
r.setex("product:67890:price", base_ttl + random_ttl, "99.9")

4.2 大键删除的优雅方案

对于超过1MB的大键，建议采用渐进式删除：

def safe_delete_big_key(key):
    if r.memory_usage(key) > 1024000:  # 超过1MB
        # 使用UNLINK替代DEL
        r.unlink(key)
    else:
        r.delete(key)

UNLINK命令会将删除操作放到后台线程执行，避免阻塞主线程。

五、关联技术生态

5.1 Redisson分布式锁

// Java示例（Redisson技术栈）
RLock lock = redisson.getLock("cleanLock");
try {
    lock.lock();
    // 执行清理操作
} finally {
    lock.unlock();
}

在集群环境中执行清理操作时，必须配合分布式锁使用，避免多个节点同时执行清理任务。

5.2 Codis集群方案

在Codis架构中执行跨分片清理：

# 使用codis-admin工具
codis-admin --proxy=proxy-list.txt --command="scan 0 match 'cart:*' count 1000" | xargs codis-admin --delete

这种方案需要特别处理分片边界问题，建议在业务低谷期执行。

六、技术方案选型矩阵

七、总结与展望

经过多个618、双11大促的考验，我们总结出缓存清理的黄金法则：预防优于治疗，分散优于集中，异步优于同步。随着Redis 7.0推出的Function特性，未来可以实现更智能的缓存管理：

# Redis 7.0 Function示例
redis.register_function('smart_clean', function(keys, args)
    local threshold = tonumber(args[1])
    local cursor = 0
    repeat
        local res = redis.call('SCAN', cursor, 'MATCH', 'product:*')
        cursor = tonumber(res[1])
        for _, key in ipairs(res[2]) do
            local idle = redis.call('OBJECT', 'IDLETIME', key)
            if idle > threshold then
                redis.call('UNLINK', key)
            end
        end
    until cursor == 0
end)

这种服务端脚本的执行效率比客户端方案提升3-5倍，代表着未来缓存管理的发展方向。