AutoMQ 介绍
Apache Kafka 自诞生之日起，就以其卓越的设计和强大的功能，很快成为了流系统领域的事实标准。它不仅定义了现代流系统的架构，更以其独特的分布式日志抽象，为实时数据流的处理和分析提供了前所未有的能力。Kafka 的成功，在于它能够满足各种规模企业对于高吞吐量、低延迟数据处理的需求，经过多年的发展铸就了极其丰富的 Kafka 生态并被广泛应用于各种生产场景。
然而，随着云计算和云原生技术的飞速发展，Kafka 面临的挑战也日益严峻。传统的存储架构已难以适应云环境下用户对更优成本、弹性的诉求，这引发了大家对 Kafka 存储模型的重新思考。分层存储（Tiered Storage）一度被视为可能的解决方案，它试图通过将数据分层存储在不同的介质上，来降低成本并延长数据的生命周期。但实践表明，这种方法并没有彻底解决 Kafka 的痛点，反而增加了系统的复杂性和运维难度。
AutoMQ 是一个源代码开放的 Kafka 分叉项目，通过存算分离的方式将 Kafka 的存储层替换成了基于 S3 和 EBS 的共享存储架构，并且复用了 Kafka 100% 的计算层代码，保证了对 Kafka API 协议和生态的完全兼容。如下图所示，通过这种创新的共享存储架构，不仅获得了共享存储带来的技术和成本优势，彻底解决了原有 Kafka 在成本、弹性等方面的弊病，同时不会牺牲延迟。
与其他流系统的对比
|
特性
|
AutoMQ
|
Apache Kafka
|
Confluent
|
Apache Pulsar
|
Redpanda
|
Warpstream
|
|
Apache Kafka 兼容性[1]
|
原生 Kafka
|
原生 Kafka
|
原生 Kafka
|
非 Kafka
|
Kafka 协议兼容
|
Kafka 协议兼容
|
|
是否开源
|
是
|
是
|
否
|
是
|
是
|
否
|
|
无状态 Broker
|
是
|
否
|
否
|
是
|
否
|
是
|
|
P99 延迟
|
单位数毫秒延迟
|
单位数毫秒延迟
|
单位数毫秒延迟
|
单位数毫秒延迟
|
单位数毫秒延迟
|
> 1200毫秒
|
|
持续自平衡
|
是
|
否
|
是
|
是
|
是
|
是
|
|
扩展/缩减效率
|
以秒计
|
以小时/天计
|
以小时计
|
以小时计(缩减);
以秒计(扩展)
|
以小时计
以秒计 (仅限企业版)
|
以秒计
|
|
Spot 实例支持
|
是
|
否
|
否
|
否
|
否
|
是
|
|
分区重新分配
|
以秒计
|
以小时/天计
|
以小时计
|
以秒计
|
以小时计
以秒计 (仅限企业版)
|
以秒计
|
|
组件
|
代理
|
代理
ZooKeeper
(非 KRaft)
|
代理
ZooKeeper
(非 KRaft)
|
代理
ZooKeeper
BookKeeper
代理
(可选)
|
代理
|
代理元数据服务器
|
|
持久性
|
由 S3/EBS 保证[2]
|
由 ISR 保证
|
由 ISR 保证
|
由 BookKeeper 保证
|
由 Raft 保证
|
由 S3 保证
|
|
跨可用区网络费用
|
否
|
是
|
是
|
是
|
是
|
否
|
[1] Apache Kafka 兼容性的定义来自这篇
博客。
[2] EBS 持久性：在 Azure、GCP 和阿里云上，区域 EBS 副本跨多个可用区。在 AWS 上，通过在不同可用区的 EBS 和 S3 Express One Zone 进行双写来确保持久性。
创新的存储架构
更新内容
- fix(log): 修复消费者偏移负载缺失的问题，作者@superhx，PR #1606
- fix(auto_balancer): 修复潜在的内存泄漏 (#1612)，作者@SCNieh，PR #1613
- fix(build): 修复e2e测试版本检查，作者@ShadowySpirits，PR #1624
- fix(build): 更新 docker-compose.yaml，作者@ShadowySpirits，PR #1628
关于我们
AutoMQ 是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队，曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念，重新设计并实现了 Apache Kafka 和 Apache RocketMQ，带来高达 10 倍的成本优势和百倍的弹性效率提升。
🌟 GitHub 地址：
https://github.com/AutoMQ
💻 官网： https://www.automq.com?utm_source=oschina
👀 B 站：
AutoMQ 官方账号
🔍 视频号：AutoMQ