> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 与多级存储的区别
> AutoMQ 使用对象存储为主存储，无需额外复制，显著节省存储与计算资源，并支持秒级分区迁移及超高性价比EBS使用。
AutoMQ 使用对象存储作为核心的存储服务，而 Apache Kafka 从 3.6.0 版本开始也引入了 [KIP-405 ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)多级存储方案，利用对象存储来卸载历史数据。
AutoMQ 的[概述▸](/zh/automq/architecture/s3stream-shared-streaming-storage/overview)由 WAL（Write-Ahead Logging）存储和数据主存组成，而 Kafka 多级存储则包含一级的 EBS 存储和二级的对象存储。通常，开发者可能认为 AutoMQ 的 WAL 存储与 Kafka 的一级 EBS 存储相似，但实际上，它们存在本质差异。本文将介绍 AutoMQ 相较于 Apache Kafka 多级存储的优势和不同点。
## 架构区别
参考 [KIP-405 ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)的设计，Apache Kafka 分级存储版本采用了两级存储的思路，存储模块依赖本地磁盘以及对象存储。消息数据首先写入本地磁盘，再通过转冷的策略异步上传到对象存储。由于本地磁盘介质存在损坏风险，因此根据副本策略，每一份消息需要经过 ISR 机制跨节点复制到多个磁盘上。
如今，在公共云环境部署分级存储版本，Apache Kafka 的架构并未改变，仍旧使用 EBS 作为本地磁盘的替代，消息仍旧需要复制到多份 EBS 上。总结而言，**Apache Kafka 仍旧将 EBS 视作普通的块设备存储介质** ，跟本地机房的一块物理硬盘没有本质的区别。
AutoMQ 采用了对象存储作为主要存储方式，无存储分级概念。然而，为优化存储效率，如减少写入对象存储的延迟、提升海量分区的写入效率，AutoMQ 引入了 WAL 存储机制。具体架构对比如下：
由于 WAL 存储可以采用 EBS 作为存储介质，开发者可能认为其与 Kafka 的一级存储有相似之处。然而，WAL 存储在设计理念和实现上与 Kafka 存在根本差异，包括存储职责、存储效率、存储空间、存储介质、持久性和多 AZ 容灾设计等方面。请参考下表了解具体差异：
| -
| WAL 存储
| Kafka Tier 1 Storage
|
| ------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------- |
| 职责
| 类似数据库的 Binlog，用于快速的数据持久化写入和故障时数据恢复（Recovery）。
| 核心的数据存储，提供读、写和回放等职责。
|
| 存储效率
| 集中式存储，将节点所有分区的数据混合存储在一个 WAL 文件或对象中，提供高写入效率和低 IOPS 消耗。
| 分散式存储，系统采用独立的文件列表来存储各分区数据，导致写入效率低且 IOPS 消耗高。
|
| 存储空间
| 占用空间较少，如 10GiB，且具备确定性。
| 占用空间大且不确定，需要进行容量评估，单节点通常需要数百 GiB。
|
| 存储介质
| 根据延迟等级和持久性需求，可选择云厂商提供的块存储、对象存储或文件存储。
| 通常建议选择本地硬盘或云供应商提供的块存储服务。
|
| 持久性保证
| 利用云存储服务中的多副本或 EC（Erasure Coding）技术，数据持久性通常可达到 99.999% 至 99.999999999% 的可靠性。
| Apache Kafka 的 ISR 副本机制提供可靠性，但不保证持久性指标。
|
| 多 AZ 容灾
| 云厂商提供的 Regional EBS、对象存储和文件存储（如 AWS EFS 和 FSx）均具备多可用区（AZ）数据持久性，并且免除跨 AZ 复制流量费用。
| 使用 ISR 实现跨可用区 (AZ) 数据复制，并将产生跨 AZ 流量复制费用。
|
## 成本优势
Apache Kafka 分级存储版本架构中仍旧将第一级 EBS 存储作为主存储对外提供读写服务，每个 Kafka 分区至少需要在第一级存储上保留最后一个活跃的 Segment 。这会导致如下现象：
* EBS 空间不确定，和集群分区数正相关。
* 生产环境需要预留较大的 EBS 空间，降低风险。
* EBS 预留成本高，分级存储降本空间有限。
**举例：**
以 Apache Kafka 默认配置为例，每个 segment 大小默认为 1GB，如果活跃的分区数为 1000 个，则仍然需要预留 1TB 的 EBS。
AutoMQ 的架构中将对象存储作为主存储，EBS 定位用于故障恢复的 WAL，实现上为一个**循环穿透写入的裸设备** 。每个 AutoMQ 的 Broker 节点仅需要 2GB 的 EBS 卷，并且可以保证仅暂存大约 500MB 的临时数据（上述空间大小均可自定义配置）。
上述设计使得 AutoMQ 对 EBS 的空间消耗**具备确定性** ，EBS 的存储开销极低，一块 2GB 的 EBS 卷每月花费仅 1 元。
## 运维优势
由于 Apache Kafka 多级存储架构中的一级存储空间不固定，每个分区遗留在 EBS 上的数据也不固定，所以在弹性伸缩、故障迁移等需要分区移动时，耗时也不确定，无法快速伸缩。
而 AutoMQ 的缓冲区里仅有不超过 500MB 的数据是在需要上传到对象存储中的，可以做到秒级完成上传，进而能支持秒级的分区转移。
以 Confluent 的案例来看，在一个大流量集群，扩容操作在非多级存储架构需要耗时 43 小时，在多级存储架构仍然需要耗时 1.4 小时。
## 总结
AutoMQ 相较于 Apache Kafka 多级存储方案，是一个量变引起质变的过程，通过架构优化，使得 AutoMQ 可以做到「无状态」，任意伸缩，秒级分区迁移。相反， Apache Kafka 多级存储架构仍然是一个优化方案，仍然是有状态，很难完成轻量的伸缩和分区迁移。