AI写代码的缓存4条红线：误用清单与spec禁止条款

AI时代，架构设计的模式变了吗？架构师的职责变了吗？准备在云栈社区开始一个《AI时代的架构设计100讲》系列，这是第9讲。

缓存架构系列前四讲聊了模式、一致性、并发、准入。这一讲，聊聊缓存的误用。

有架构师说：缓存是万金油，哪里有问题，让AI加个缓存就能优化。但如果让AI无约束地滥用缓存，反而会适得其反。AI最常见的4类缓存误用，必须把“不许这么干”写进spec。

误用一：把缓存作为服务与服务之间传递数据的媒介

如上图：

1. 服务1和服务2约定好key和value，通过缓存传递数据；
2. 服务1将数据写入缓存，服务2从缓存读取数据，从而完成两个服务之间的通信。

这个方案存在什么问题？

1. 数据管道、数据通知这类场景，MQ更加适合；
2. 多个服务关联同一个缓存实例，会导致服务耦合。

误用二：使用缓存未考虑雪崩

常规的缓存玩法如上：先读缓存，缓存不命中，再读数据库。

什么时候会产生雪崩？如果缓存挂掉，所有请求会瞬间压到数据库上。如果未提前做容量预估，数据库可能被压垮——而在缓存恢复之前，数据库很可能一直都起不来，最终导致系统整体不可服务。

如何应对潜在的雪崩？提前做容量预估：如果缓存挂掉，数据库依然能扛住，才能采用上述方案，否则就需要进一步设计。具体来说，有两类常见方案。

方案一：高可用缓存

如上图：使用高可用缓存集群，一个缓存实例挂掉后，能够自动做故障转移。

方案二：缓存水平切分

如上图：使用缓存水平切分，一个缓存实例挂掉后，不至于所有流量都压到数据库上。

误用三：调用方缓存数据

如上图：

1. 服务提供方缓存，向调用方屏蔽数据获取的复杂性——这个没问题；
2. 服务调用方也缓存一份数据，先读自己的缓存再决定是否调用服务——这个有问题。

该方案存在什么问题？

1. 调用方需要关注数据获取的复杂性；
2. 更严重的是：服务修改db里的数据、淘汰了服务cache之后，很难通知调用方淘汰它自己cache里的数据，从而引发数据不一致；
3. 有人会说，服务通过MQ通知调用方淘汰数据。但这样一来，下游服务得依赖上游的调用方了？分层架构设计可不是这么玩的。

误用四：多服务共用缓存实例

如上图：服务A和服务B共用一个缓存实例（注意，这里并不是通过这个缓存实例交互数据）。

这个方案存在什么问题？

1. 可能导致key冲突，彼此冲掉对方的数据；
2. 不同服务的数据量、吞吐量不一样，共用一个实例很容易导致一个服务把另一个服务的热数据挤出去；
3. 共用一个实例也会造成服务之间的耦合，违背微服务架构“数据库、缓存私有”的设计原则。

建议的玩法是：

如上图：各个服务私有化自己的数据存储，对上游屏蔽底层的复杂性。

AI时代，这份误用清单变了吗？

先说结论：坑没变，踩坑的变了——由程序员变成了AI。

没变的部分：四类误用的后果没变——耦合、雪崩、不一致、互相挤兑。这些判断与是不是AI写代码没有关系。

变了的部分：代码由AI来写，而这四类坑它全都会犯。图省事，拿缓存当管道；不会主动做容量预估；爱给调用方加一份缓存；不会主动拆分实例。它并不知道我们踩过这些坑。我们要做的，是把误用清单写成spec的禁止条款。

spec示例（markdown格式，可以直接复制）

# 缓存使用spec（红线）

## 模式
缓存仅作“读加速”用途：
- 各服务私有化缓存实例；
- 提供方缓存，对调用方屏蔽数据获取复杂性。

## 红线
1. 禁止用缓存当服务间数据管道，数据管道与通知场景使用MQ；
2. 禁止调用方缓存服务底层数据；
3. 禁止多服务共用缓存实例，必须垂直拆分；
4. 未做容量预估与雪崩预案，禁止依赖缓存的方案上线。

## 异常与降级
1. 雪崩预案：容量预估打底，高可用缓存集群或缓存水平切分二选一；
2. cache miss时，回源数据库读取。

## 验收标准
1. 缓存宕机演练，数据库不被压垮；
2. 新增缓存用法，不违反四条禁止条款；
3. 雪崩预案有演练记录，可查询。

这四件事写清楚，AI要踩这四类坑，就没那么容易了。

总结

缓存使用小技巧：

1. 服务与服务之间，不要通过缓存传递数据；
2. 如果缓存挂掉可能导致雪崩：容量预估打底，做高可用缓存，或者做水平切分；
3. 调用方不宜再单独使用缓存存储服务底层的数据：防不一致、防反向依赖；
4. 不同服务，缓存实例要做垂直拆分；
5. AI时代，将误用清单写成spec禁止条款，评审逐条打勾。

知其然，知其所以然。思路比结论更重要。