与多级存储的区别
AutoMQ 使用对象存储作为核心的存储服务，而 Apache Kafka 从 3.6.0 版本开始也引入了 KIP-405 多级存储方案，利用对象存储来卸载历史数据。
AutoMQ 的概述▸由 WAL（Write-Ahead Logging）存储和数据主存组成，而 Kafka 多级存储则包含一级的 EBS 存储和二级的对象存储。通常，开发者可能认为 AutoMQ 的 WAL 存储与 Kafka 的一级 EBS 存储相似，但实际上，它们存在本质差异。本文将介绍 AutoMQ 相较于 Apache Kafka 多级存储的优势和不同点。
架构区别
参考 KIP-405 的设计，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 多级存储架构仍然是一个优化方案，仍然是有状态，很难完成轻量的伸缩和分区迁移。