存储计算分离模式 · 复习笔记

系统架构设计师考试 · 第14章云原生架构设计理论与实践

📚 所属章节：第14章云原生架构设计理论与实践 → 14.2 云原生架构内涵 → 14.2.3 主要架构模式 → 第4小节

📖 教材出处：《系统架构设计师教程（第2版）》第489-490页

🎯 知识点定位：云原生七大主要架构模式之一（与服务化、Mesh化、Serverless、分布式事务、可观测、事件驱动并列）

⭐ 考点等级：下午案例分析高频考点，常与"无状态/有状态服务"、"CAP理论"、"弹性"等结合考查

一、核心定义（必背）

📌 一句话定义

存储计算分离模式：在云环境中，将各类暂态数据（如 session）、结构化和非结构化持久数据都采用云服务来保存，从而把"存储"从"计算"中剥离出来，让计算节点保持无状态化，以获得更好的弹性。

📐 模式的本质

该模式的本质是"无状态化改造"——把应用中"有状态"的部分（数据）下沉到分布式存储/云服务中，让计算层（业务进程）变成"无状态"的，从而：

计算节点可以自由调度、随意扩缩容；
避免分布式 CAP 困境，获得更好的可用性（A）和分区容错性（P）；
支持云原生架构的弹性、敏捷等关键特性。

二、提出背景与理论基础

1. CAP 理论的困境

⚡ 关键论点（教材原文）

分布式环境中的 CAP 困难主要是针对有状态应用，因为无状态应用不存在 C（一致性）这个维度，因此可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。

维度	含义	有状态应用	无状态应用
C 一致性	所有节点同一时刻看到相同数据	需要保证（困难）	不存在该维度
A 可用性	每个请求都能得到响应	受限	很好
P 分区容错性	网络分区时系统仍能工作	受限	很好
弹性	动态扩缩容能力	差（需同步状态）	强（任意调度）

2. 与其他云原生原则的关系

弹性原则存储计算分离是实现弹性的必要前提——计算节点无状态后才能任意扩缩容。
韧性原则计算节点故障时可以快速被替代，因为状态在云服务中持久化。
服务化原则微服务"无状态设计原则"的具体落地手段。

三、典型应用场景与数据分类

💡 哪些数据应该"分离"到云服务

教材推荐把以下三类数据全部采用云服务保存：

数据类别	说明	典型示例	云服务对应
暂态数据	临时的、会话期间的数据	Session、临时缓存、Token	分布式缓存（如云 Redis）
结构化持久数据	表结构清晰的业务数据	订单、用户、交易记录	云数据库（RDS、OLTP/OLAP）
非结构化持久数据	无固定格式的大文件数据	图片、视频、日志、文档	对象存储（OSS、S3）、块存储、文件存储

四、特殊场景及补救方案

⚠️ 教材重点警示（易考点）

并非所有状态都适合"无脑下沉"到远端缓存。仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，例如：

交易会话数据太大，传输开销巨大；
需要不断根据上下文重新获取，频繁远程调用。

✅ 教材给出的补救方案

采用 "时间日志 + 快照（或检查点）" 的方式，实现重启后快速增量恢复服务，从而减少不可用对业务的影响时长。

原理图解：

本地保留少量状态 ──► 持续写入"时间日志"（增量记录） │ ├──► 定期生成"快照/检查点"（全量备份） │ ▼ 故障 ──► 重启 ──► 加载最近快照 + 重放增量日志 ──► 快速恢复

五、在云原生七大架构模式中的定位

14.2.3 节列出的七大主要架构模式：

序号	模式	核心解决问题
1	服务化架构模式	模块拆分、解耦
2	Mesh 化架构模式	中间件 SDK 与业务代码解耦
3	Serverless 模式	免运维、按需调度
4	存储计算分离模式	无状态化、提升弹性
5	分布式事务模式	跨服务数据一致性（XA/BASE/TCC/SAGA/AT）
6	可观测架构	Logging / Tracing / Metrics
7	事件驱动架构（EDA）	异步集成、服务韧性

六、相关延伸知识（教材其他章节呼应）

1. 微服务设计原则中的呼应（第14.3.2节）

微服务与数据层之间的纵向约束：对于有数据存取（即有状态）的微服务而言，通常使用计算与存储分离方式，将数据下沉到分布式存储，通过这个方式做到一定程度的无状态化。

2. 云原生与大数据的结合（第14.1节）

大量企业使用容器替换 AI、大数据的基础平台，正是利用了容器"天然的计算与存储分离架构"等特点，在性能大幅提升的同时控制成本。

3. 与 Serverless 的协同

Serverless 不适合有状态应用（云调度不会同步状态，可能导致上下文丢失）。因此 Serverless 应用通常必须结合存储计算分离，把状态外置到云服务（缓存、数据库、对象存储）中。

4. 与"无状态云服务高可用"的呼应（第14.2.1节）

云原生架构定义部分指出："如果应用把'有状态'部分都交给了云服务（如缓存、数据库、对象存储等），由于云服务本身具备极强的高可用能力，那么应用本身会变成更薄的'无状态'应用，高可用故障带来的业务中断会降至分钟级。"

七、知识结构图（脑图速记）

存储计算分离模式 │ ├── 【为什么】 │ ├── CAP 困境只针对"有状态应用" │ ├── 无状态应用 → 无 C 维度 → 高 A + 高 P → 高弹性 │ └── 云原生弹性原则的必要前提 │ ├── 【是什么】 │ └── 把数据交给云服务，让计算节点变"无状态" │ ├── 【做什么】（三类数据外置） │ ├── 暂态数据（Session）── 分布式缓存 │ ├── 结构化持久数据 ── 云数据库 │ └── 非结构化持久数据 ── 对象/块/文件存储 │ ├── 【特殊情况】（不适合远端缓存的场景） │ ├── 会话数据过大 │ ├── 频繁上下文获取 │ └── 解决方案：时间日志 + 快照（检查点） │ └── 【关联知识】 ├── 微服务无状态设计 ├── Serverless 模式 ├── 容器化部署 └── 云原生弹性/韧性原则

八、考点提炼与答题模板

🎯 高频考点 1：选择题/概念题

提问角度："存储计算分离模式" 的核心思想是什么？

标准答案：通过把暂态数据（如 session）、结构化和非结构化持久数据采用云服务来保存，使计算节点变为无状态应用，从而绕开 CAP 中的一致性约束，获得更好的可用性、分区容错性和弹性。

🎯 高频考点 2：原因分析题

提问角度：为什么云原生架构推荐存储计算分离？

答题要点（4 点）：

突破 CAP 限制：无状态应用不存在一致性维度，可同时获得高 A 与高 P；
支撑弹性扩缩容：计算节点可自由调度、增减实例；
降低故障影响：计算节点宕机不丢数据，业务中断降至分钟级；
简化运维：状态由云服务统一管理，应用更轻、更敏捷。

🎯 高频考点 3：场景应用题

提问角度：某交易系统采用了存储计算分离，但会话数据较大、上下文频繁获取，导致性能下降，应如何优化？

答题要点：使用"时间日志 + 快照（检查点）"方式，在本地保留少量必要状态并持续写日志，定期生成快照，故障重启时通过加载快照 + 重放日志实现快速增量恢复，减少业务不可用时长。

🎯 高频考点 4：综合应用题

提问角度：请说明存储计算分离与 Serverless、微服务、容器化的关系。

答题要点：

与 Serverless：Serverless 调度不同步状态，要求应用无状态，需借助存储计算分离把状态外置；
与微服务：有状态微服务通过计算与存储分离做到无状态化，符合"数据存储隔离 DSS"原则；
与容器化：容器调度的不可预知性要求应用无状态，存储计算分离是容器化部署的前置条件；
统一目标：四者共同支撑云原生应用的弹性、韧性、敏捷性。

九、易混淆点辨析

易混淆概念	区别
存储计算分离 vs 读写分离	读写分离是同一数据库内主从拆分（写主读从）；存储计算分离是把存储整体从应用进程中剥离，下沉到云服务。
存储计算分离 vs 数据存储隔离（DSS）	DSS 强调"每个微服务有自己的私有数据"，是微服务间的横向隔离；存储计算分离是单个服务内计算与存储的纵向分层。
无状态 vs 存储计算分离	无状态是目标/结果；存储计算分离是实现手段。
云存储 vs 存储计算分离	云存储是具体的产品形态（OSS、RDS 等）；存储计算分离是架构模式，倡导使用云存储。

十、一句话记忆口诀

🧠 速记

"数据上云端，计算变无状；
CAP 不再难，弹性自然涨；
会话太庞大，日志加快照。"