空间型架构是什么
空间型架构面向突发高并发：处理单元是无状态或轻量状态的应用实例，可随负载快速增减；业务数据尽量驻留在内存数据网格中并按分片复制，避免数据库成为吞吐瓶颈；变更通过异步队列持久化到数据库。它用内存读写的低延迟换取对数据库依赖的削减，代价是数据一致性与持久化窗口的设计复杂度明显上升。
什么时候值得用
典型适用场景是读多写少、峰值流量波动大且能接受短暂数据延迟的业务，例如活动页的秒杀余量展示、票务库存展示与区域化会话缓存。若业务必须强一致、每笔写入都要落库确认，这套架构的复杂度换不来收益。落地前要先想清两件事：故障时允许多大的数据丢失窗口，以及缓存与数据库不一致时如何对账与修复。
基本信息
| 处理单元 | 无状态或轻量状态的应用实例，可快速增减 |
|---|---|
| 内存数据网格 | 分片复制业务数据，避免数据库成为吞吐瓶颈 |
| 异步持久化 | 通过消息队列把变更写入数据库 |
| 主要收益 | 内存读写延迟低，扩容响应快，抗突发流量 |
| 主要代价 | 一致性与持久化窗口的设计复杂度显著上升 |
组件与职责
| 组件 | 职责 | 工程要点 |
|---|---|---|
| 处理单元 | 承载无状态业务逻辑 | 会话不落在单元本地 |
| 内存网格 | 分片复制业务数据 | 副本数与恢复时间目标挂钩 |
| 写队列 | 异步持久化变更 | 积压与降级策略提前定义 |
| 读路由 | 按分片键定位数据 | 再平衡时流量平滑过渡 |
典型使用场景
- 秒杀与抢购类活动，峰值流量达到平时的数十倍
- 读多写少的展示型业务，允许秒级的数据延迟
- 区域化会话与购物车数据，就近读写降低访问延迟
- 数据库成为吞吐瓶颈，需要用内存层承接主要读流量
内存数据在多个节点同时故障时可能丢失，需要评估可接受的数据丢失窗口，并明确写队列积压时的降级与恢复手段。
缓存与数据库双写却没有对账机制时，不一致会长期累积，通常在业务对账时才暴露，修复成本远高于早期投入。