系统架构 · 缓存机制

场景 1 · 商品详情 5w QPS, DB 单机上限 3000 — Cache Aside 标准读写模板

详情页读多写少, 直连 DB 必挂。标准模板: 读走缓存 miss 回源回填, 写先更库再删缓存; Redis 故障时降级读库而不是报错。

// go-redis v9: github.com/redis/go-redis/v9
func GetItem(ctx context.Context, id int64) (*Item, error) {
    key := fmt.Sprintf("item:%d", id)
    s, err := rdb.Get(ctx, key).Result()
    if err == nil {
        return decodeItem(s), nil                    // HIT ~0.5ms
    }
    if !errors.Is(err, redis.Nil) {
        log.Warn("redis down, fallback db", "err", err) // 缓存故障不把请求打死
    }
    it, err := db.GetItem(ctx, id)                    // MISS 回源 ~20ms
    if err != nil {
        return nil, err
    }
    _ = rdb.Set(ctx, key, encodeItem(it), 30*time.Minute).Err() // 关键: 回填必带 TTL
    return it, nil
}

func UpdatePrice(ctx context.Context, id, price int64) error {
    if err := db.UpdatePrice(ctx, id, price); err != nil { return err } // 先动库
    return rdb.Del(ctx, "item:"+strconv.FormatInt(id, 10)).Err()       // 再删缓存
}

上线后 DB 峰值 QPS 从 5w 压到 900, P99 从 120ms 降到 2ms。

场景 2 · 抢券开场 5w 并发怼同一个 key — singleflight 合并回源防击穿

券热点 key 到期瞬间, 5w 并发同时 miss 回源, DB 连接池秒没。进程内 singleflight 把同 key 并发合并成一次回源。

var g singleflight.Group // golang.org/x/sync/singleflight

func GetCoupon(ctx context.Context, id int64) (*Coupon, error) {
    key := fmt.Sprintf("coupon:%d", id)
    if v, err := rdb.Get(ctx, key).Result(); err == nil {
        return decodeCoupon(v), nil
    }
    v, err, _ := g.Do(key, func() (any, error) { // 关键: 同 key 并发只放 1 个进 DB
        c, err := db.GetCoupon(ctx, id)
        if err != nil {
            return nil, err
        }
        rdb.Set(ctx, key, encodeCoupon(c), 10*time.Minute)
        return c, nil
    })
    if err != nil {
        return nil, err
    }
    return v.(*Coupon), nil
}

开抢瞬间 DB 回源从 5w QPS 压到每实例 1 QPS, 全集群 < 40 QPS。

场景 3 · 爬虫拿 id=-1 疯狂试探 — RedisBloom 前置拦截穿透

攻击流量专查不存在的商品 id, 空值缓存也挡不住海量不同 id。Bloom 说"没有"就一定没有, 直接 404。

# 大促前建过滤器: 错误率 1%, 预期 500 万商品 id, 内存约 6MB
BF.RESERVE bf:item 0.01 5000000

# 商品上架/审核通过时登记 (漏登记会误杀, 上架要双写)
BF.ADD bf:item 10086             # → 1

# 读路径最前置: 说"没有"就一定没有, 直接 404
BF.EXISTS bf:item 99999999       # → 0, 不查缓存更不查 DB

接入后穿透类 DB 查询从 3w QPS 降到接近 0, 误杀率 1% 内可接受。

场景 4 · 凌晨定点 DB 报警 30 秒 — TTL 抖动把雪崩摊成细流

定时任务批量回填的 key 全部 TTL=1800s, 到期也整批同秒 — 每 30 分钟一次 DB 突刺。写入时叠加随机抖动摊开。

// 错法: 整批 Set 同一个 TTL — 同生同死, 30 分钟后一起暴毙
// 对法: base + rand 抖动, 把"整批到期"摊成 10 分钟的细流
base := 30 * time.Minute
items := loadAllHotItems()
pipe := rdb.Pipeline()
for _, it := range items {
    jitter := time.Duration(rand.Intn(600)) * time.Second // 0~10min 抖动
    pipe.Set(ctx, "item:"+it.ID, encode(it), base+jitter)
}
if _, err := pipe.Exec(ctx); err != nil {
    log.Error("warm up failed", "err", err)
}
// 关键: Pipeline 一把发, 上万 key 预热从 30s 缩到 2s, 且到期不再扎堆

场景 5 · 用户详情 P99 40ms → 3ms — Caffeine 本地 + Redis 两级缓存

Redis 一次 ~1ms, 万级 QPS 下网络与序列化都是钱。本地 Caffeine 扛 topN 热点, Redis 兜底, Spring Boot 一段配置搞定 L1。

# application.yml — L1 本地 Caffeine, L2 Redis 在代码里兜底
spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=10000,expireAfterWrite=60s,refreshAfterWrite=30s
# 说明: 本地只放读多改少数据; 60s 过期 = 多实例不一致窗口上限
# 收益: 用户详情 P99 40ms → 3ms, Redis QPS 降 80%

场景 6 · 单分片 CPU 100% 而集群空闲 — 热 key 探测与本地兜底

明星官宣, 排行榜 key 被打爆; Cluster 总 QPS 不高但一个分片先死。排查靠 --hotkeys, 修法是热 key 下沉到进程内。

# 现象: 7003 分片 CPU 100% 打满, 其余分片空闲 — 典型热 key 击穿单分片
redis-cli -p 7003 info stats | grep instantaneous_ops
# → instantaneous_ops_kps:98000  (其余分片 < 8000)

# 排查: --hotkeys 需要 LFU 计数 (maxmemory-policy allkeys-lfu)
redis-cli --hotkeys
# → summary 区列出命中最多的 key: 例如 'rank:live:10086'

# 修法: 客户端本地兜底缓存 1s, 热 key 的 95% 读不再出网
# 关键: 分片上限 = 单核, 热 key 不下沉到本地, 加机器也没用

场景 7 · 大促 0 点缓存冷启动, DB 开抢即挂 — 预热脚本

不预热的话 0 点第一分钟全是 miss, DB 直接 ERROR 1040。提前 1 小时把 top 商品灌入 Redis 并登记 Bloom。

#!/bin/bash
# warmup.sh — 大促前 1 小时跑: top 50 万商品灌入 Redis + 登记 Bloom
while read -r id json; do
  ttl=$((86400 + RANDOM % 3600))  # 预热批也抖动, 别再制造集中过期
  redis-cli SET "item:$id" "$json" EX "$ttl" >/dev/null
  redis-cli BF.ADD bf:item "$id" >/dev/null
done < top_items.txt
# 收益: 开抢首分钟 DB QPS 从峰值 8w 压到 1.2w

场景 8 · 首页 banner 不能有半秒空窗 — 逻辑过期方案

物理过期瞬间必然 miss + 同步回源, 对"永不能空窗"的热点不行。逻辑过期: key 永不设物理 TTL, 值里埋 expireAt, 过期了返回旧值 + 异步刷新。

type cachedBanner struct {
    Data     json.RawMessage `json:"d"`
    ExpireAt int64           `json:"e"` // 逻辑过期时间戳(ms)
}

func GetBanner(ctx context.Context) json.RawMessage {
    s, _ := rdb.Get(ctx, "banner:home").Result() // key 不设物理 TTL
    var cb cachedBanner
    _ = json.Unmarshal([]byte(s), &cb)
    if time.Now().UnixMilli() < cb.ExpireAt {
        return cb.Data                        // 未到期: 直接用
    }
    if mu.TryLock() {                         // 只放一个协程刷新 (mu 为包级 Mutex)
        go func() {
            defer mu.Unlock()
            if d, err := loadBanner(ctx); err == nil {
                nc := cachedBanner{d, time.Now().Add(5 * time.Minute).UnixMilli()}
                rdb.Set(ctx, "banner:home", marshal(nc), 0) // 关键: 永不过期
            }
        }()
    }
    return cb.Data                            // 刷新期间返回旧值, 零空窗
}

场景 9 · 改价后偶发读到旧值, 大促前必须根治 — 延迟双删

"先库后删"仍有小概率被"慢半拍的读线程"回填旧值, 主从延迟还会让旧值多活几秒。延迟双删做补刀。

func UpdatePrice(ctx context.Context, id, price int64) error {
    key := "item:" + strconv.FormatInt(id, 10)
    if err := db.UpdatePrice(ctx, id, price); err != nil {
        return err                                // 先动库
    }
    rdb.Del(ctx, key)                             // 第一删: 立刻清
    time.AfterFunc(800*time.Millisecond, func() { // 迟来的第二删
        rdb.Del(ctx, key)
    })
    return nil
    // 关键: 800ms 覆盖"读旧值→回填"窗口, 也覆盖主从延迟大头
}

场景 10 · 一个 8MB 的大 value 把网卡打满 — 拆分与压缩

全量商品详情序列化 8MB, 一次 GET 网络传 8MB、反序列化 100ms, 命中率 99% 也白搭。拆字段按需取 + 大字段压缩。

// 拆: 8MB 全量详情 → hash 三字段, 列表页只取 base (~20KB)
rdb.HSet(ctx, "item:42", "base", baseJSON, "sku", skuJSON, "desc", descHTML)
base, _ := rdb.HGet(ctx, "item:42", "base").Result()

// 压: 大字段 gzip 后再存, 4MB desc → 600KB, 网卡不再被打满
var buf bytes.Buffer
zw := gzip.NewWriter(&buf)
zw.Write(descRaw)
zw.Close()
rdb.Set(ctx, "item:42:desc", buf.Bytes(), 30*time.Minute)
// 读回: gzip.NewReader(bytes.NewReader(b)) 解压, ~5ms CPU 换 85% 带宽