AI时代架构设计，给AI的4条缓存红线（9/100）

《AI时代的架构设计100讲》
第9讲：AI时代架构设计，给AI的4条缓存红线

AI时代，架构设计变了吗？架构师的职责变了吗？准备新起一个AI时代的架构设计系列，初定100讲，每周更新2-3讲，这是第9讲。

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

有架构师说：缓存是万金油，哪里有问题，让AI加个缓存，就能优化。如果让AI无约束的滥用缓存，会适得其反，4类缓存AI常见误用，必须把"不许这么干"写进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示例（md格式），可以直接复制：

# 缓存使用spec（红线）

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

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

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

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