如何在Golang中使用缓存提升性能_内存缓存设计要点

为什么直接用 sync.Map 不适合做业务缓存

因为 sync.Map 是为高并发读多写少场景优化的底层结构，缺乏过期、淘汰、统计等缓存必需能力。它不支持 TTL（Time-To-Live），不能自动驱逐旧数据，也没有命中率监控接口——这些在真实服务中几乎必须。

• 用 sync.Map 手动实现过期逻辑，会引入定时器或懒检查，极易导致内存泄漏或时序错误
• 没有容量限制，缓存无限增长，可能触发 GC 压力或 OOM
• 无法区分“未命中”和“值为 nil”，业务层需额外包装，增加出错概率

推荐方案：用 github.com/patrickmn/go-cache 快速落地

这个库轻量（单文件）、无依赖、线程安全，覆盖绝大多数内存缓存需求。它默认使用 time.Now() 判断过期，支持基于容量的 LRU 淘汰（需手动启用），且 API 直观。

import "github.com/patrickmn/go-cache"

c := cache.New(5*time.Minute, 10*
time.Minute) // default TTL, cleanup interval
c.Set("user:123", &User{Name: "Alice"}, cache.DefaultExpiration)
if x, found := c.Get("user:123"); found {
    u := x.(*User)
}

• cache.New(5*time.Minute, 10*time.Minute) 中第一个参数是条目默认过期时间，第二个是后台清理 goroutine 的执行间隔
• 设为 cache.NoExpiration 表示永不过期；设为 0 则使用 New 时传入的默认值
• 不启用 LRU 时，仅靠过期时间清理；启用后需调用 c.SetMaxEntries(n)，否则无容量约束

自研简单缓存要注意的三个边界条件

如果因合规或定制需求必须自建，绕不开这三个点：并发安全、过期判断、空值穿透。漏掉任一都可能引发线上故障。

• 用 sync.RWMutex 而非 sync.Mutex：读操作远多于写，避免读阻塞读
• 过期检查必须在 Get 时做（而非仅靠定时清理）：防止返回已过期数据
• 对空结果也要缓存（如 nil 或 ErrNotFound），并设较短 TTL（如 60s），防止缓存击穿

示例关键逻辑：

func (c *Cache) Get(key string) (any, bool) {
    c.mu.RLock()
    e, ok := c.items[key]
    c.mu.RUnlock()
    if !ok {
        return nil, false
    }
    if time.Since(e.expireAt) > 0 { // 过期检查不可省
        c.Delete(key)
        return nil, false
    }
    return e.value, true
}

何时不该用内存缓存

当数据跨进程共享、需要强一致性、或单机内存受限时，本地内存缓存反而成为瓶颈。

• 微服务多实例部署下，各节点缓存不同步，Set("order:789", v) 只影响当前机器
• 库存类数据要求“减库存即生效”，用内存缓存会导致超卖——必须走 Redis + Lua 或数据库行锁
• 缓存对象过大（如单个 >1MB）或总量超 500MB，会显著拖慢 Go 的 GC 周期，延迟毛刺明显

这种情况下，宁愿用带租约的 Redis，也不要拼凑一个“看起来快”的内存方案。