行业动态
mp.weixin.qq.com ·
@架构师之路
AI时代进程内缓存怎么写spec？架构师之路第8讲
架构师之路《AI时代的架构设计100讲》第8讲讨论进程内缓存：相比Redis等进程外缓存，进程内缓存读取不访问后端、时延更低，但多节点数据多份、一致性难保障，可通过单节点通知或MQ通知其他节点更新，代价是耦合或引入MQ复杂度。文章重申分层架构的无状态准则，认为进程内缓存默认禁止、例外放行，仅适用于只读数据、极高并发透传场景和允许一定不一致的业务。作者指出AI写代码时倾向自作主张加本地Map缓存，因此需在spec中写清模式声明、红线约束、异常与降级、验收标准四件事，并给出可复制的spec示例（正文截断）。
AI推荐理由 作者沈剑（架构师之路）以系列第8讲形式，系统梳理进程内缓存的适用场景、一致性方案（单节点通知、MQ通知）与无状态准则，并给出AI时代将'默认禁止、例外放行'写入spec的四要素（模式声明、红线约束、异常与降级、验收标准）。内容为架构经验总结，非新事实或可验证数据，但工程实践参考价值明确；正文在spec示例处截断，完整模板未展示。
62
正文
原创 58沈剑 2026-09-30 08:12 北京
> 《AI时代的架构设计100讲》
>
> 第8讲：让AI慎用进程内缓存
AI时代，架构设计变了吗？架构师的职责变了吗？准备新起一个AI时代的架构设计系列，初定100讲，每周更新2-3讲，这是第8讲。
缓存簇前三讲，聊了缓存的操作模式、一致性补偿、并发性能——都是"怎么用对"。这一讲反过来，聊一个"慎用"的东西：进程内缓存——以及，怎么防止AI帮我们滥用。老规矩，先搞清楚方案本身，再说spec的事。
**什么是进程内缓存？**
大部分时候，大家会用redis这类进程外缓存服务。有时候，也会使用进程内缓存。将一些数据缓存在站点，或者服务的进程内，这就是进程内缓存。
进程内缓存的实现载体，最简单的，可以是一个带锁的Map。又或者，可以使用第三方库，例如：leveldb。
**进程内缓存有什么好处？**
答：与没有缓存相比，进程内缓存的好处是：数据读取不再需要访问后端，例如数据库。一来节省了内网带宽，二来响应时延会更低。
**进程内缓存有什么缺点？**
答：统一缓存服务虽然多一次网络交互，但仍是统一存储。
如上图，站点和服务中的多个节点访问统一的缓存服务，数据统一存储，容易保证数据的一致性。
而进程内缓存，如上图，如果数据缓存在站点和服务的多个节点内，数据存了多份，一致性比较难保障。
**如何保证进程内缓存的数据一致性？**
答：保障进程内缓存一致性，有几种方案。
第一种方案，可以通过单节点通知其他节点。如上图：写请求发生在server1，在修改完自己内存数据与数据库中的数据之后，可以主动通知其他server节点，也修改内存的数据。
这种方案的缺点是：同一功能的一个集群的多个节点，相互耦合在一起，特别是节点较多时，网状连接关系极其复杂。
第二种方案，可以通过MQ通知其他节点。如上图：写请求发生在server1，在修改完自己内存数据与数据库中的数据之后，给MQ发布数据变化通知，其他server节点订阅MQ消息，也修改内存数据。
这种方案虽然解除了节点之间的耦合，但引入了MQ，使得系统更加复杂。
上面两种方案，节点数量越多，数据冗余份数越多，数据同时更新的原子性越难保证，一致性也就越难保证。
**为什么不能频繁使用进程内缓存？**
答：分层架构设计，有一条准则：站点层、服务层要做到无数据无状态，这样才能任意加节点水平扩展，数据和状态尽量存储到后端的数据存储服务，例如数据库服务或者缓存服务。
可以看到，站点与服务的进程内缓存，实际上违背了分层架构设计的无状态准则，故一般不推荐使用。
**什么时候可以使用进程内缓存？**
答：以下情况，可以考虑使用进程内缓存。
1. 只读数据，可以考虑在进程启动时加载到内存。
2. 极其高并发、透传后端压力极大的场景，可以考虑使用进程内缓存。例如秒杀业务，并发量极高，需要站点层挡住流量，可以使用进程内缓存。
3. 一定程度上允许数据不一致的业务。例如一些计数场景、运营场景，页面对数据一致性要求较低，可以考虑使用进程内页面缓存。
再次强调，进程内缓存的适用场景并不如redis/mc广泛，不要为了炫技而使用。更多的时候，还是老老实实使用redis/mc吧。
**那么问题来了，到了AI时代，这条"慎用"的红线，spec该怎么写？**
先说结论：思路没变，执行者变了。
**没变的部分：无状态准则没变——进程内缓存，默认禁止、例外放行。这个判断，和是不是AI写代码，没有关系。**
**变了的部分：代码由AI写，而AI特别喜欢自作主张加本地缓存"优化性能"——它看到频繁访问的数据，会觉得"放个本地Map更快"，顺手就加了。不写死，它一定会这么干。我们干的活，是把"默认禁止"写进spec。**
**一份进程内缓存的准入spec，至少写清四件事：**
1. 模式声明；
2. 红线约束；
3. 异常与降级；
4. 验收标准；
**spec示例（md格式），可以直接复制：**
> # 进程内缓存使用spec
>
> ## 模式
>
> 1. 默认使用redis；
>
> 2. 进程内缓存，仅闲鱼以下三种场景：
>
> - 只读数据，进程启动时加载到内存
>
> - 极其高并发、透传后端压力极大
>
> - 允许一定程度数据不一致
>
> ## 红线
>
> 1. 禁止未经声明，擅自引入进程内缓存；
>
> 2. 站点/服务层必须保持无状态，禁止以"性能优化"为由破坏该准则；
>
> 3. 使用进程内缓存，必须同时给出一致性方案。
>
> ## 异常与降级
>
> 1. 一致性方案按例外场景选择：节点通知 / MQ通知 / TTL容忍；
>
> 2. cache miss时，回源数据库读取。
>
> ## 验收标准
>
> 1. 任意加节点水平扩展；
>
> 2. 新增进程内缓存代码，必须能追溯到本spec中的例外声明；
>
> 3. 一致性方案有日志，可查询、可统计。
这四件事写清楚，AI想帮我们"滥用"进程内缓存，就没那么容易了。
**总结**
1. 进程内缓存省带宽、低时延，但数据存多份，一致性难保障；
2. 一致性方案有两种：单节点通知（耦合网状）、MQ通知（引入MQ更复杂）；节点越多，越难保证；
3. 进程内缓存违背无状态准则，默认不用；三种例外：只读启动加载、极高峰挡流量、允许不一致；
4. AI时代，把"默认禁止"写进spec：例外必须显式声明，防AI自作主张加本地缓存。
知其然，知其所以然。
思路比结论更重要。
前篇简介：
《[让AI操作缓存，spec怎么写（5/100）](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651981660&idx=1&sn=26661f449a2f96ce32042b4b4e1198f5&scene=21#wechat_redirect)》
《[解决缓存不一致，spec怎么写（6/100）](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651981668&idx=1&sn=8b96fb9bb927400395b84f9e1c2389d4&scene=21#wechat_redirect)》
《[10W并发无锁缓存，spec怎么写？（7/100）](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651981687&idx=1&sn=b51500a9b81dffbb3059e07999ecef43&scene=21#wechat_redirect)》
今晚直播，欢迎预约：
[跳转微信打开](https://wechat2rss.bestblogs.dev/link-proxy/?k=676d32f2&r=1&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMjM5ODYxMDA5OQ%3D%3D%26mid%3D2651981698%26idx%3D1%26sn%3Dd4d230c9e7fa2ed48e6d176e4ab52b90)