当前位置：首页 > news >正文

为什么高级工程师会说：Cache 是一种抽象，而不是优化

news 2026/5/12 14:48:33

很多工程师对 Cache 的理解只有一句话：

“数据库扛不住了，前面加个 Redis。”

但多做几年系统你会慢慢发现，真正成熟的设计不是“用了缓存”，而是整个系统的数据面天然假设缓存是存在的。两种思维写出来的代码，结构、演进能力、故障表现完全不在一个维度。

一、一个非常经典的 Redis 用法

大多数系统起步时都是这样的：

func GetArticle(ctx context.Context, articleID string) (*Article, error) { key := "article:" + articleID // 先查 Redis val, err := redis.Get(ctx, key).Result() if err == nil { var article Article _ = json.Unmarshal([]byte(val), &article) return &article, nil } // miss 查 DB article, err := mysql.GetArticle(ctx, articleID) if err != nil { return nil, err } // 回填 Redis data, _ := json.Marshal(article) redis.Set(ctx, key, data, 10*time.Minute) return article, nil }

看起来很合理，对吧？然后更新逻辑：

func UpdateArticleTitle(ctx context.Context, articleID string, title string) error { err := mysql.UpdateTitle(ctx, articleID, title) if err != nil { return err } redis.Del(ctx, "article:"+articleID) return nil }

再往后业务越来越多：

func UpdateArticleContent(...) func PublishArticle(...) func DeleteArticle(...) func BanArticle(...)

很快你会发现，每个方法都得重复同一个动作——redis.Del(...)。

二、问题从“能用”变成“失控”

这时候系统会悄悄进入一种状态：缓存逻辑开始污染业务逻辑。

你的业务代码里渐渐塞满了这些东西：

redis.Get/redis.Set/redis.Del
各种 TTL
手动拼的 cache key
singleflight、防穿透
预热脚本、降级开关

接着你会亲身遭遇这些线上噩梦：

有人忘记删缓存，数据不一致
key 拼错一个字母，缓存永远不命中
TTL 配置各异，数据新鲜度乱成一团
一个热 key 把 DB 打爆
Redis 一挂，缓存穿透直接干死整个库
双写、删除顺序、延迟双删……一致性怎么也调不稳

到最后你会发现，业务逻辑变成了：

业务 = 业务逻辑 + 缓存管理 + 一致性维护

系统的复杂度被缓存问题反向吞噬了。

为什么会这样？因为这个系统在架构上的真实依赖关系是：

Service ├── MySQL └── Redis

业务层完全知道 Redis 的存在，而且必须主动管理它。这才是问题的根源。

三、换个思路：把 Cache 变成抽象

真正成熟的系统会怎样设计？业务层只和一种存储打交道。

type ArticleStore interface { Get(ctx context.Context, articleID string) (*Article, error) Update(ctx context.Context, article *Article) error Delete(ctx context.Context, articleID string) error }

业务代码变成：

func ShowArticle(ctx context.Context, store ArticleStore, articleID string) error { article, err := store.Get(ctx, articleID) if err != nil { return err } fmt.Println(article.Title) return nil }

业务层完全不知道 Redis 存在，甚至不知道下面有没有缓存。它只依赖一个抽象的ArticleStore。

Redis 被藏在实现内部：

type CachedArticleStore struct { db DBStore cache CacheStore } func (s *CachedArticleStore) Get(ctx context.Context, articleID string) (*Article, error) { article, err := s.cache.Get(ctx, articleID) if err == nil { return article, nil } article, err = s.db.Get(ctx, articleID) if err != nil { return nil, err } _ = s.cache.Set(ctx, articleID, article) return article, nil } func (s *CachedArticleStore) Update(ctx context.Context, article *Article) error { err := s.db.Update(ctx, article) if err != nil { return err } _ = s.cache.Delete(ctx, article.ID) return nil }

四、这两种代码真正的区别，远不止“封装一下”

很多人看到这里会说：“不就是把 Redis 操作包进一个结构体里吗？”

完全不是。核心区别在于控制权和认知边界。

第一种设计里，业务层知道一切：

知道 Redis 存在
知道 cache key 规则
知道 TTL 含义
知道失效策略
知道回源逻辑
缓存是一个“外挂”

第二种设计里，业务层只知道一件事：

我有一个ArticleStore，它能给我数据，并且我不用关心它怎么保证性能和一致性。

至于底层到底是用 Redis、本地内存、singleflight、预热、降级，还是未来换成分布式缓存，全部属于存储系统的内部实现细节。

这时，Cache 已经不是一个“性能补丁”，它是一个抽象。

五、更高级的地方：语义开始取代实现

成熟的存储层不会只封装 Redis API，它会封装数据一致性语义。

接口上很可能变成这样：

// Get may return stale data within 10 seconds (最终一致，低延迟). Get(ctx, articleID) // Read-after-write consistency guaranteed in same region (写后读一致性). Get(ctx, articleID)

此时，系统对外暴露的不再是“Redis + MySQL”这种技术栈，而是“一种确定的数据访问语义”。

调用方无需知道底下是缓存还是数据库，它只需要知道：这次读取我愿意接受什么程度的新鲜度。

这就是把缓存从“技巧”提升到了“系统模型”的层次。