AutoMQ: 一款真正的云原生 Kafka 解决方案 [开源项目]

手动赞一个

redpanda 再打包?

@liprais 和 redpanda 设计理念完全不同哦，没用使用任何 redpanda 的代码，在 fork Apache Kafka 的基础上修改而来。设计理念上比较接近的是 warpstream ，但是 warpstream 只依赖了对象存储，latency 表现没有 AutoMQ 好。代码是开源的，有兴趣的话可以看看我们开源仓库代码哈，我们在 kafka logsegment 上做了个切面，做了无状态的设计。

和 Kafka 分层存储 KIP-405 比有啥区别，不都是放到对象存储么

@superhxnju 随着 Apache Kafka 3.6.0 的发布，KIP-405 多级存储存储方案终于问世，虽然该特性仍处于早期访问阶段，但确实仍然有不少开发者询问 AutoMQ 的架构相较于 KIP-405 核心优势在哪里。

如果我们在云上部署 Apache Kafka 或者 AutoMQ for Kafka （以下简称 AutoMQ Kafka ），确实两个架构有一定的相似性，都是基于 EBS 和 对象存储（ S3 ）的部署形态，虽然在存储介质的选型上是一致的，但实际上如何用这两类存储的思想是不同的。

首先来讲 EBS：
- Apache Kafka 的架构将 EBS 视作普通的块设备存储介质，跟本地机房的一块物理硬盘没有本质的区别，所以 Apache Kafka 会基于 EBS 做数据复制，一般要求 3 副本。
- AutoMQ Kafka 将 EBS 视作高可靠、高可用的云存储服务，充分利用 EBS 自带 3 副本的可靠性（ 5 个 9 ～ 9 个 9 的可靠性）以及其在可用区内和可用区之间的故障转移能力，这使得 AutoMQ Kafka 可以避免在 EBS 之上做额外的复制，从而节省大量的存储、网络和计算资源。

再来看对象存储（ S3 ）：
- Apache Kafka 将 S3 用于第二级存储，第一级存储构建在 EBS 之上，从设计上来看，每个 Kafka Topic 的分区，至少最后一个活跃的 Segment 需要留在第一级存储之上。这也导致多级存储方案中的第一级 EBS 存储将使用多少存储空间是不固定的，往往跟分区数量有关系。
- AutoMQ Kafka 将 S3 作为主存，EBS 定位为高速写入缓冲区，更多的是一个低延迟的持久化缓存。因此 AutoMQ Kafka 的每个 Broker 仅需要 2GB 的 EBS 卷，其中仅 500MB 不在 S3 上的 Delta 数据（可配置）。

EBS 作为缓冲区，所以存储空间具备确定性，使得 AutoMQ Kafka 架构在 EBS 存储上开销极低，一块 2GB 的 EBS 卷每月花费仅 1 元，同时缓冲区里面仅最多有不超过 500MB 的数据是在 S3 上不存在的，可以做到秒级完成 S3 上传，进而能支持秒级的分区转移。

相反，多级存储架构中的一级存储空间不固定，需要对 EBS 进行容量评估，这往往是一件很困难的事情，所以我们仍然需要为每个 Broker 节点预置大容量的 EBS 卷。另一方面，每个分区遗留在 EBS 上的数据也不固定，所以分区移动时间也不确定，也没办法快速伸缩。以 Confluent 给出的案例来看，在一个大流量集群，扩容操作在非多级存储架构需要耗时 43 小时，在多级存储架构需要耗时 1.4 小时。可以看出，多级存储方案虽然大大缓解了 Kafka 架构上固有的问题，但无法像 AutoMQ Kafka 架构一样做到无状态。

总结一下，AutoMQ Kafka 的云原生架构相较于多级存储方案，是一个量变引起质变的过程，通过架构优化，使得 AutoMQ Kafka 做到「无状态」，任意伸缩，秒级分区转移。相反，多级存储架构是一个优化方案，仍然是有状态。

火钳刘明！
顺便问下对于那些不想用云服务的 kafka 用户有解决方案吗？

@wan0573 公有云的 EBS 并不都是高持久性的，阿里云是高持久的，但 AWS 的 GP3 等的持久性只有 99.8% - 99.9%

看起来很厉害呀！

@9of6 感谢回复哈，针对你的问题，我这边谈下我的看法。公有云针对 EBS 一般都针对场景提供多种云盘的 SKU 。如果对持久性有更高的要求，像在 aws 上其实可以使用 io2(有 3 个 9 的持久性，并且支持多重挂载可以做更快的 failover)。对于 AutoMQ 来说，使用更好规格的云盘其实并不会导致大量的成本上升(这算是 AutoMQ 本身设计的一个亮点)，因为 AutoMQ 本质上把云盘作为一个具备持久性性的写入 cache ，加速写的。一般这个大小只要配置 3GB 左右的云盘即可打满单机百 MB/s 的带宽。 此外，云的基础设施底座还在不断发展的，像 GCP 上就有支持跨可用区的云盘，可以预见，国内外主流云厂商提供更加丰富的云盘 SKU 和跨可用区云盘能力的跟进是指日可待的》

@metaluo 对于 AutoMQ 来说，在云上肯定是可以发挥最大的弹性、成本优势(主要是云上的云盘、对象存储和按需使用的计算资源)。如果你是纯粹不使用云的场景，私有部署的话，也就是意味着没有云上的这些基础设施底座，对于弹性、成本这方面的效果就会差一些，但是仍然是可以使用 AutoMQ 替换 Kafka 来提升运维效率和降低成本的。在纯私有环境使用 AutoMQ 一般要求有 HDFS 或者 minio 这样的存储底座即可，AutoMQ 自身的自动流量重平衡、极速分区移动、写低成本存储层的能力仍然是具备的。

@wan0573 有什么本地快速试用的方案嘛

@wan0573 AutoMQ 这个有实际的数据吗？对比 Apache Kafka 的优势，可以量化的？

@cyifei2023 相比 Apache Kafka 在运维、成本等各方面都有明显提升的。官网有个性能白皮书可以下载参考哈，所有数据是如何来的是完全公开并且可以自行复现的。

@gezilzq 开源仓库有个 quick start 可以参考，直接本地通过 localstack 启动，不依赖云： https://github.com/AutoMQ/automq-for-kafka

大家如果想了解 AutoMQ 背后的技术，可以访问我们的官网，或者加入我们的社区群： https://www.automq.com/

有 helm 文件就好了，直接在本地 k8s 集群试用一下

@zzl22100048 虽然没上 k8s ，但是快速启动的话，使用我们提供的容器化启动的方式也可以哈，十分便捷的。可以参考:https://docs.automq.com/docs/automq-s3kafka/SMKbwchB3i0Y0ykFm75c0ftAnCc