Hotdry.
归档
systems-engineering

Kafka磁盘less架构：从Shared Nothing到对象存储的存储革命

深度分析KIP-1150提案和AutoMQ实现的磁盘less Kafka架构，探讨从Shared Nothing到对象存储的根本性转变，以及17倍成本降低背后的技术原理。

Kafka 磁盘 less 架构：从 Shared Nothing 到对象存储的存储革命

引言：当 Kafka 遇见云原生

在云原生时代，即使是 Apache Kafka 这样的分布式系统标杆也面临着前所未有的挑战。传统的 Shared Nothing 架构虽然在本地数据中心表现出色，但在云环境中却暴露出了存储成本高昂、运维复杂性高、弹性不足等痛点。

随着 KIP-1150（Diskless Kafka）提案的提出和 AutoMQ 等项目的实际落地，我们看到了 Kafka 存储架构正在发生根本性变革：从依赖本地磁盘的 Shared Nothing 模式向基于对象存储的磁盘 less 架构演进。

核心架构：计算与存储的彻底解耦

传统 Shared Nothing 架构的局限性

传统 Kafka 采用 Shared Nothing 架构，每个 Broker 节点都强耦合本地存储。这种设计在云环境中面临四大核心挑战：

存储成本问题：以 AWS EBS GP3 卷为例，单价 $0.08/GiB/ 月，但 Kafka 三副本配置下实际成本达到 $0.24/GiB。若预留 50% 存储空间应对数据增长，成本翻倍至 $0.48/GiB。对于长期存储大量数据的系统，这种成本结构不可持续。

运维复杂性：水平扩展 Broker 时的分区数据迁移是资源密集型过程，会大量占用网络带宽和磁盘 I/O，影响正常读写操作。大量分区的迁移可能持续数小时甚至数天，严重影响集群可用性。

性能瓶颈：本地磁盘 I/O 限制在处理历史数据冷读操作时尤为明显。实时数据流处理与历史数据回放的 I/O 冲突导致响应延迟，影响整体处理性能。

缺乏弹性：Broker 节点与本地磁盘的强耦合限制了集群的动态适应能力，无法快速扩缩容应对流量峰值，无法充分利用云的弹性特性。

磁盘 less 架构的技术实现

AutoMQ 等磁盘 less 实现通过彻底重构存储层来解决这些痛点：

流式写入 S3：构建全新的存储层，直接将数据流式传输到 S3 或兼容对象存储。Broker 成为无状态轻量节点，摆脱了本地磁盘依赖。

计算存储分离：通过解耦计算与存储，支持二者独立扩缩容。夜间扩容不再需要数据迁移，新 Pod 可在几秒内启动完成。

共享存储架构：采用创新的共享存储架构，将 EBS+S3 结合实现存算分离。EBS 作为共享存储，Broker 与存储解耦，确保低延迟的同时获得弹性。

成本革命：17 倍降低背后的技术密码

基准测试数据

在 1 GB/s 吞吐、跨 3 个可用区的负载场景下，AutoMQ 1.6.0 与自管理 Apache Kafka 的成本对比：

成本项目 AutoMQ 自管理 Kafka 节省倍数
跨 AZ 网络成本 $128 / 月 $138,240 / 月 1080 倍
计算资源 $3,867 / 月 $24,510 / 月 6.3 倍
存储资源 $8,905 / 月 $63,446 / 月 7 倍
总成本 $12,900 / 月 $226,196 / 月 17.5 倍

成本优化机制解析

跨 AZ 网络成本激减（1080 倍节省）： 传统 Kafka 通过 Leader-Follower 复制实现数据备份，在 1 GB/s 吞吐、3 副本配置下产生巨额跨 AZ 流量（月均 13.8 万美元）。磁盘 less 架构直接写入 S3，仅需传输少量元数据和热数据，月均跨 AZ 成本从 $138,240 降至 $128。

计算资源优化（6.3 倍节省）： 传统 Kafka 计算与存储强耦合，云厂商本地磁盘容量限制导致必须使用更多计算实例。磁盘 less 架构支持计算与存储独立扩缩容，彻底解决资源浪费问题。

存储资源优化（7 倍节省）： 传统 Kafka 依赖昂贵的预配置块存储（EBS），需按峰值容量配置。S3 按量付费模式仅需为实际数据付费，避免过度配置浪费。

延迟性能的权衡与优化

在成本大幅降低的同时，性能表现如何？基准测试显示，AutoMQ 1.6.0 的生产端 P99 延迟约 823ms。

对于有严格低延迟要求的场景，AutoMQ 企业版提供灵活选项：区域级 EBS 或 FSx 作为 WAL（预写日志）存储后端，可实现 P99 延迟低于 10ms，同时仍借助 S3 实现低成本长期存储。

技术挑战与解决方案

对象存储延迟优化

基于 S3 构建 Kafka 面临的主要挑战是对象存储的访问延迟。通过以下技术实现延迟优化：

分层存储策略：热数据存储在低延迟介质（EBS），冷数据迁移至 S3，根据访问模式自动分层。

批量写入优化：聚合小消息为大批次写入，减少对象存储 API 调用开销。

并行读取机制：利用 S3 的并行读取能力，提高历史数据回放性能。

数据一致性与可靠性

磁盘 less 架构通过多级保障确保数据可靠性：

多副本机制：在 S3 层面实现数据的多重备份，确保数据持久性。

写入确认机制：实现端到端的写入确认，确保数据成功写入 S3 后才向客户端确认。

故障自动恢复：Broker 故障时，由于数据已持久化到 S3，可快速启动新 Broker 接管服务。

实际部署考量

Kubernetes 集成

AutoMQ 1.6.0 原生支持 Strimzi Operator，可与 Kubernetes 无缝集成：

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: automq-cluster
spec:
  kafka:
    version: 3.6.0
    replicas: 3
    storage:
      type: jbod
      volumes:
      - type: ephemeral  # 磁盘less模式，无需持久化存储

数据湖集成

通过 Table Topic 功能增强，支持零 ETL 数据传输到 Apache Iceberg 等数据湖：

-- 创建支持Iceberg的Topic
CREATE TABLE iceberg_orders (
  order_id BIGINT,
  customer_id BIGINT,
  order_timestamp TIMESTAMP,
  order_status STRING,
  total_amount DECIMAL(10,2)
) WITH (connector='automq', format='iceberg');

未来演进方向

Kafka.next 的愿景

基于磁盘 less 架构的实践，社区对未来 Kafka 的演进方向有了更清晰的规划：

分区概念取消：在云端对象存储环境下，分区机制不再必要，可直接提供 Key 为中心的数据访问方式。

Schema 原生支持：Broker 端原生支持数据结构定义，无需依赖外部 Schema Registry。

多租户架构：从设计之初内置多租户支持，创建新租户环境的瞬时低成本操作。

插件化扩展：通过标准扩展点实现自定义消息处理、存储格式等功能。

结论：存储架构的时代变革

Kafka 磁盘 less 架构的演进代表了分布式存储系统从传统 Shared Nothing 模式向云原生对象存储的根本性转变。AutoMQ 等项目的成功实践证明了这一方向的可行性：17 倍成本降低、秒级弹性扩展、简化的运维复杂度。

这种变革不仅是技术架构的升级，更是思维模式的转变：从本地磁盘依赖向云原生对象存储的思维跃迁，从固定容量配置向弹性按需使用的模式转换。

对于企业而言，磁盘 less Kafka 提供了重新思考流处理架构的机会：在保持 Kafka 生态兼容性的同时，获得云原生的弹性、成本和运维优势。这预示着在云原生时代，传统的存储架构设计理念需要根本性的重新审视和演进。

参考资料：

查看归档