理解 Aerospike 的 Flexible Storage三种存储引擎怎么玩-开发者社区

1. 存储介质：先把“砖头”讲清楚

Aerospike 支持的存储介质主要有三类：

DRAM（内存）
- 读写延迟最低，成本也最高
NVMe Flash / SSD
- 非易失性存储，延迟一般在几十到几百微秒
- 容量大、价格相对便宜，是 HMA / All Flash 的主角
Intel Optane™ Persistent Memory（PMem）
- 介于内存和存储之间的持久化介质
- 延迟比 SSD 低，比 DRAM 高
- 适合用来存放索引

需要注意一个小细节：

Enterprise Edition（EE）中的 “memory” 指 shared memory
- 节点进程重启后仍然可以保留数据（持久）
Community Edition（CE）中的 “memory” 指进程内存
- 进程退出就没了（易失）

这对你选择“要不要纯内存模式并做磁盘备份”会有影响。

2. 三种 Flexible Storage 模式概览

Aerospike 的存储配置可以理解为三种“引擎模式”：

In-Memory：索引和数据都在 DRAM
Hybrid Memory Architecture（HMA）：索引在 DRAM，数据在 SSD
All Flash：索引和数据都在 Flash（SSD/ NVMe）

这三种模式都基于同样的逻辑结构：

Primary Index里保存 digest & tree info、record metadata、storage pointer
Bin 区域存放真正的字段值
Write Queue、Expiry、Defrag这些后台机制负责持久化、过期和碎片整理

下面分别拆开讲。

3. In-Memory：极致延迟的“全内存模式”

在In-Memory 模式下：

Primary Index 在 DRAM
Record 数据也在 DRAM
可选：通过 write queue 把数据备份到磁盘或 SSD（用于容灾或快速恢复）

特点：

读写延迟可以做到sub-millisecond（亚毫秒级）
访问路径最短：操作几乎全部打在内存上
适合：
- 高频读写、强实时的热点数据
- 对延迟极端敏感的业务（实时竞价、风控、部分交易场景）

代价也比较明显：

完全内存承载，成本最高
容量上限直接受限于 DRAM 规模

在 CE 中，如果没做磁盘备份，节点停机后内存数据就没了；
在 EE 中，即便用 shared memory，可以保留数据，但重启仍然要考虑恢复时的一致性与复制。

4. HMA：默认、也是最常用的“索引内存 + 数据 SSD”

Hybrid Memory Architecture是 Aerospike 的默认模式，也是大多数场景首选。

Primary Index 在 DRAM
- 所以定位一条记录只需要一次内存访问
Record 数据在 SSD / NVMe 上
- 真正的值读取通过 SSD 完成

读写路径大致是：

写入：
- 请求到达后在 DRAM 中更新索引、metadata 等
- Bin 数据写入 write queue，再顺序刷到 SSD
- 背后有 defrag 负责维护空间利用率
读取：
- 先在 DRAM 中通过索引找到 storage pointer
- 根据 pointer 定位到 SSD 上的数据块并读取

优点非常突出：

仍然可以做到sub-millisecond 的读写延迟（得益于 DRAM 索引 + 顺序写 SSD）
与纯内存相比，服务器的内存占用可以降低 5-10 倍
大部分容量由 SSD 提供，成本可控且扩容方便

适用场景：

绝大多数在线业务：用户画像、推荐特征、广告投放、订单状态等
需要高读写性能，但数据量已经远超可用内存容量

5. All Flash：索引也上 SSD 的“极致省内存模式”

在All Flash 模式下：

Primary Index + Record 数据都在 Flash（SSD / NVMe）
DRAM 主要用于缓存和运行开销，而不再存储完整索引

要点：

延迟目标是sub 5-millisecond 级别（亚 5 毫秒）
相比 HMA，DRAM 使用进一步降低
非常适合大量小对象的场景
总体服务器占用（尤其是内存）和 HMA 类似，甚至更低

这里有两个官方限制需要记一下：

Index on Flash 必须搭配 “data on SSD”
- 也就是 All Flash 模式必须让数据也在 Flash 上
Index in PMem 不应该和 “data in memory” 组合
- 官方不建议“索引在 PMem、数据在 DRAM”的组合

适用场景：

数据量巨大，内存价格占主要成本
对延迟要求没有 HMA 那么苛刻，但仍需要毫秒级
预算敏感，又希望尽量减少服务器数量

6. Namespace 级别的精细化存储策略

Aerospike 的一个非常实用的设计是：每个 namespace 可以配置不同的存储模式。

例如：

ns_hot：
- 用户 Session、实时推荐特征
- 配置为In-Memory或HMA（DRAM + SSD）
ns_cold：
- 历史行为日志、长尾账户信息
- 配置为HMA 或 All Flash

这样你就可以在同一个集群里：

一部分数据“跑极致性能”
另一部分数据“跑性价比”

另外几个和容量相关的重要点：

每个 namespace 有固定存储量（按配置）
集群里每个节点承担大致相同的数据份额
存储空间按 replication factor（复制因子）自动分摊
Aerospike 自动做reshard + replicate保证所谓的k-safety（失去 k 个节点仍不丢数据）

7. 数据布局与写入模型：连续存放 + copy-on-write

在底层实现上，Aerospike 的记录有几个特性：

Record 数据是连续存放的（便于顺序读写与 defrag）
单条记录最大尺寸支持8 MiB
新版本写入采用copy-on-write
- 每次更新都会写入一份新的版本
- 旧版本在 defrag 或过期后被回收

配合 copy-on-write，Defragmenter（碎片整理器）会：

统计每个 block 中的“活跃记录数”
当一个 block 的利用率低于阈值时，把里面剩下的记录搬到其他 block
回收整个 block 作为新的可写空间

这保证：

SSD 上长期运行不会因为碎片严重导致性能雪崩
写放大被控制在可接受范围内

8. 可用性与可靠性：随机分布 + 多副本

在可靠性上，Aerospike 通过以下策略保证数据安全：

多副本存储（replication factor）
- 每条记录有多个副本，分布在不同节点
- 节点挂掉时，其他节点会接管服务并触发数据重建
自动 reshard & replicate
- 当节点新增、下线或故障时，集群会自动重新分片和复制
- 保证配置的 k-safety（“最多丢 k 个节点仍不丢数据”）始终满足
随机数据分布，降低不可用比例
- 通过随机/哈希分布，把数据均匀地铺在所有节点
- 即使多个节点同时损失，不可用的数据比例也会显著小于“丢失节点数 / 总节点数”

官方给过一个直观例子：

在一个 10 节点集群上，replication factor = 2，
如果有 2 个节点同时挂掉，在触发重新复制之前，不可用的数据大约只有 2% 左右（约 1/50）。

这就是“随机分布 + 多副本”的效果：
即便发生低概率事故，业务受到的影响仍然可控。

9. 实战建议：如何选择合适的存储模式？

最后给几个实践中的选型建议，方便你在写博客时顺带总结：

如果你极度在乎延迟，并且数据量可控
- 优先考虑：In-Memory + 磁盘备份
- 典型场景：实时竞价、风控决策、核心撮合状态
如果你想“性能 + 成本”相对平衡（大多数情况）
- 使用默认的HMA（索引内存 + 数据 SSD）
- 多数在线业务都可以在这个模式下跑得很舒服
如果数据量巨大、预算敏感，但还能接受 1~5ms 级延迟
- 选择All Flash模式
- 把内存主要用于缓存和索引元数据，尽量把成本压到 SSD 上
混合策略：按 namespace 细分
- 热数据 namespace：HMA / In-Memory
- 冷数据 namespace：HMA / All Flash
- 一套集群，分区承载不同价格带的数据