public User getUser(Long id) {
    String key = "user:" + id;
    String cached = redis.get(key);

    // 注意区分"key 不存在"和"key 存在但值为空"
    if (cached != null) {
        if ("NULL".equals(cached)) return null; // 之前缓存的空值
        return JSON.parseObject(cached, User.class);
    }

    User user = db.selectById(id);
    if (user != null) {
        redis.set(key, JSON.toJSONString(user), 30, MINUTES);
    } else {
        // 缓存空值，设置较短的 TTL
        redis.set(key, "NULL", 5, MINUTES);
    }
    return user;
}

布隆过滤器 = 位数组（bit array）+ 多个哈希函数

写入：对 key 用 k 个哈希函数得到 k 个位置，全部置 1
BF.add("user:1001")
  → hash1("user:1001") = 3,  hash2("user:1001") = 17,  hash3("user:1001") = 42
  → bitArray[3] = 1,  bitArray[17] = 1,  bitArray[42] = 1

查询：检查 k 个位置是否全为 1
BF.mightContain("user:9999")
  → hash1 = 5, hash2 = 23, hash3 = 42
  → bitArray[5] = 0 → 肯定不存在！直接返回 null

特点：可能误判"存在"（false positive），但不会误判"不存在"
Redis 有 RedisBloom 模块，也可用 Redisson 的 RBloomFilter

public User getUser(Long id) {
    String key = "user:" + id;
    String cached = redis.get(key);
    if (cached != null) return parse(cached);

    // 尝试获取分布式锁（SET NX EX）
    String lockKey = "lock:" + key;
    boolean locked = redis.set(lockKey, "1", NX, 10, SECONDS);

    if (locked) {
        try {
            // 双重检查：可能别的线程已经重建了缓存
            cached = redis.get(key);
            if (cached != null) return parse(cached);

            User user = db.selectById(id);
            redis.set(key, toJSON(user), 30, MINUTES);
            return user;
        } finally {
            redis.del(lockKey); // 释放锁
        }
    } else {
        // 没拿到锁 → 短暂等待后重试
        Thread.sleep(50);
        return getUser(id); // 递归重试
    }
}

// 缓存值中嵌入过期时间
class CacheData<T> {
    T data;
    long expireTime; // 逻辑过期时间戳
}

// 查询时发现逻辑过期 → 异步线程重建缓存，当前线程返回旧数据
if (System.currentTimeMillis() > cacheData.expireTime) {
    // 提交异步任务重建缓存（用线程池 / 协程）
    executor.submit(() -> rebuildCache(key, id));
}
return cacheData.data; // 返回旧数据（可接受短暂过期）

方案 1：过期时间随机化
// 基础 TTL + 随机偏移量 → 避免集中过期
int baseTTL = 30 * 60; // 30 分钟
int randomOffset = ThreadLocalRandom.current().nextInt(60, 300); // 1~5 分钟随机
redis.set(key, value, baseTTL + randomOffset);

方案 2：多级缓存
// L1: 本地缓存（Caffeine/Guava） → L2: Redis 分布式缓存
// 即使 Redis 宕机，本地缓存还能扛一段时间

方案 3：限流 + 降级
// 缓存大面积失效时，对 DB 查询做限流（令牌桶 / 信号量）
// 超出阈值的请求直接降级返回默认值或友好提示

方案 4：集群 + 高可用
// Redis Cluster / Sentinel 避免单点故障导致全部缓存失效

public void updateUser(Long id, User user) {
    String key = "user:" + id;

    // 第一次删除缓存
    redis.del(key);

    // 更新数据库
    db.updateById(user);

    // 延迟第二次删除（异步）
    // 延迟时间 >= 读请求的耗时（通常 500ms ~ 1s）
    executor.schedule(() -> {
        redis.del(key);
    }, 1000, MILLISECONDS);
}

方案：Canal 监听 binlog + MQ 异步删缓存

1. 业务代码正常更新 DB（无需关心缓存）
2. Canal（阿里开源）订阅 MySQL binlog
3. 解析出变更的表和 key → 发送 MQ 消息
4. 消费者收到消息 → 删除对应的 Redis key
5. 如果删除失败 → MQ 自动重试（保证最终一致）

优点：
- 业务代码与缓存解耦，不需要手动维护一致性
- MQ 重试机制保证删除一定成功
- 适合中大型项目

问题：多个应用实例各自有 L1 本地缓存，更新后如何同步？

方案：Redis Pub/Sub 广播 + MQ
1. 更新 DB 后，发送消息到 MQ（如 RocketMQ）
2. 所有应用实例订阅该 topic
3. 收到消息后，清除本地 L1 缓存中对应的 key
4. 下次读请求会重新从 L2/DB 加载

也可以用 Redis Pub/Sub：
PUBLISH cache:invalidate "user:1001"
所有订阅者收到后清除本地缓存

# 内存
maxmemory 8gb
maxmemory-policy volatile-lru  # 优先淘汰设了 TTL 的 key

# 持久化
appendonly yes
aof-use-rdb-preamble yes
save 900 1

# 安全
rename-command FLUSHALL ""    # 禁用危险命令
rename-command KEYS ""
requirepass your_strong_password

# 性能
tcp-backlog 2048
timeout 300                    # 空闲连接超时
hz 50                          # 事件循环频率（默认 10）