Skip to main content

与多级存储的区别

AutoMQ 使用对象存储作为核心的存储服务，而 Apache Kafka 从 3.6.0 版本开始也引入了 KIP-405 多级存储方案，利用对象存储来卸载历史数据。本文将介绍 AutoMQ 相较于 Apache Kafka 多级存储版本的优势和差异。

架构：EBS as Disk vs EBS as Service​

参考 KIP-405 的设计，Apache Kafka 分级存储版本采用了两级存储的思路，存储模块依赖本地磁盘以及对象存储。消息数据首先写入本地磁盘，再通过转冷的策略异步上传到对象存储。由于本地磁盘介质存在损坏风险，因此根据副本策略，每一份消息需要经过 ISR 机制跨节点复制到多个磁盘上。

如今，在公共云环境部署分级存储版本，Apache Kafka 的架构并未改变，仍旧使用 EBS 作为本地磁盘的替代，消息仍旧需要复制到多份 EBS 上。总结而言，Apache Kafka 仍旧将 EBS 视作普通的块设备存储介质 ，跟本地机房的一块物理硬盘没有本质的区别。

公共云厂商提供 EBS 服务是具备高可靠、高可用服务能力保障的，AutoMQ 将 EBS 视作云存储服务 ，充分利用 EBS 自带 3 副本的可靠性（5 个 9 ～ 9 个 9 的可靠性）以及其在可用区内和可用区之间的故障转移能力。因此，AutoMQ 可以避免在 EBS 之上做额外的复制，从而节省大量的存储、网络和计算资源。

成本：EBS as Storage vs EBS as Recovery WAL​

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 元。

弹性：小时级迁移 vs 秒级迁移​

由于 Apache Kafka 多级存储架构中的一级存储空间不固定，每个分区遗留在 EBS 上的数据也不固定，所以在弹性伸缩、故障迁移等需要分区移动时，耗时也不确定，无法快速伸缩。

而 AutoMQ 的缓冲区里仅有不超过 500MB 的数据是在需要上传到对象存储中的，可以做到秒级完成上传，进而能支持秒级的分区转移。

以 Confluent 的案例来看，在一个大流量集群，扩容操作在非多级存储架构需要耗时 43 小时，在多级存储架构仍然需要耗时 1.4 小时。

总结​

AutoMQ 相较于 Apache Kafka 多级存储方案，是一个量变引起质变的过程，通过架构优化，使得 AutoMQ 可以做到「无状态」，任意伸缩，秒级分区迁移。相反， Apache Kafka 多级存储架构仍然是一个优化方案，仍然是有状态，很难完成轻量的伸缩和分区迁移。