查询缓存与结果缓存设计

无缓存：    SELECT ...  → 解析 → 计划 → 读页 → 返回（每毫秒级）
有缓存：    SELECT ...  → 命中缓存 → 返回（微秒级）

命中缓存 ≈ 省掉 99% 的数据库开销。

# my.cnf (MySQL 5.7 时代)
query_cache_type = DEMAND
query_cache_size = 64M

行级 key：  user:{userId}
列表 key：  feed:list:{lastId}:{pageSize}
聚合 key：  stat:orders:{date}:{status}

# Redis 结果缓存伪代码
def get_orders(user_id):
    key = "orders:user:%d:list" % user_id
    data = redis.get(key)
    if data is not None:
        return deserialize(data)              # 命中
    rows = db.query("SELECT ... WHERE user_id=%s", user_id)
    redis.setex(key, ttl=300, serialize(rows)) # 未命中，回源并写入
    return rows

正确顺序（Cache Aside）：
  1. 更新数据库
  2. 删除缓存（下一次 miss 时回源新值）

延迟双删（解决并发读回写旧值）：
  1. 更新数据库
  2. 删除缓存
  3. sleep 50~100ms
  4. 再次删除缓存（清掉期间被写回的旧值）

def update_user(user_id, payload):
    db.update("UPDATE users SET ... WHERE id=%s", user_id, payload)
    redis.delete("user:%d" % user_id)          # 1. 先更新 DB
    time.sleep(0.05)                           # 2. 等待可能的旧值回写窗口
    redis.delete("user:%d" % user_id)          # 3. 延迟双删

业务写库 → binlog → Canal/Debezium → 缓存失效服务 → Redis DEL
好处：业务代码无侵入，一个变更统一驱动所有缓存失效。
代价：引入消息链路，存在秒级延迟。

命中率 = 缓存命中的请求数 / 总请求数
统计埋点：get 命中数 / get 总数（按 key 前缀聚合）

# Redis 侧总体指标
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"
# keyspace_hits 与 keyspace_misses 之比即整体命中率

# Redis 侧
redis-cli --stat                     # 实时统计
redis-cli info stats | grep evicted  # 淘汰监控
redis-cli monitor | head -50         # 短期采样分析 key 分布

判断标准三连问：
  1. 同一查询是否被高频重复？        （频率）
  2. 数据变更是否频繁？              （写放大）
  3. 业务能否容忍 TTL 内的旧数据？   （一致性）
三问都通过，才值得上结果缓存。

def list_orders(user_id, page, size):
    key = "order:list:%d:%d:%d" % (user_id, page, size)
    hit = redis.get(key)
    if hit:
        return deserialize(hit)                  # 命中：0.1ms

    rows = db.query(JOIN_SQL, user_id, page, size)
    # 只缓存近 7 天热点，老订单直查
    if rows and rows[0].created_at > now() - timedelta(days=7):
        redis.setex(key, ttl=60 + randint(-10, 10),
                    serialize(rows))             # 随机抖动 TTL
    return rows

效果：
  命中率  32% → 86%
  P99    350ms → 42ms
  数据库 QPS  2000 → 260

import threading

lock_by_key = {}

def get_orders_with_mutex(user_id):
    key = "orders:user:%d" % user_id
    data = redis.get(key)
    if data is not None:
        return deserialize(data)
    lock = lock_by_key.setdefault(key, threading.Lock())
    with lock:
        data = redis.get(key)                    # 双检：避免重复回源
        if data is not None:
            return deserialize(data)
        rows = db.query("SELECT ... WHERE user_id=%s", user_id)
        redis.setex(key, ttl=60, serialize(rows))
    return rows

效果：热 key 过期瞬间，回源 DB 的次数从 N 次收敛为 1 次。
配合「逻辑过期 + 异步续期」，可以让热数据永不过期：
  1. 缓存里存逻辑过期时间（不依赖 Redis TTL）
  2. 读到逻辑过期 → 返回旧值，同时异步重建
  3. 下一个请求就拿到新值

节省的 DB QPS ≈ 总请求数 × 命中率
平均查询耗时 ≈ (1 - 命中率) × 回源耗时 + 命中率 × 缓存耗时

示例：命中率 86%，回源 350ms，缓存 0.1ms
  → 平均查询耗时 ≈ 14% × 350 + 86% × 0.1 ≈ 49ms