与 WarpStream 的区别

AutoMQ 和 WarpStream 都利用对象存储来存储消息数据，两者在架构上有一些相似之处。本文将重点介绍 AutoMQ 与 WarpStream 之间的差异和比较。

架构：重写协议 vs 存算分离

WarpStream 重新实现了 Apache Kafka 协议，利用对象存储 S3 构建 Kafka 功能。该架构未复用任何 Kafka 代码，而是通过 WarpStream Agent 组件重新实现 Kafka 功能和 API。应用生产的消息直接由 Agent 转发到对象存储 S3，Agent 本身无需要实现存储逻辑，是完全无状态的架构设计。

AutoMQ 在技术架构上则采用了存算分离的无状态设计思路，选择复用 Apache Kafka 计算层代码 ，将原本基于本地存储的 Apache Kafka 存储层分离到基于 S3 对象存储的远端存储，仅在存储层寻找极小切面进行替换，保持了上层协议和功能接口的不变性。

WarpStream 架构

AutoMQ 架构

兼容性：部分兼容 vs 100% 兼容

WarpStream 选择重新实现 Apache Kafka 协议，目前仅适配生产消费消息的主要 API 接口 ，对于事务消息、ExactlyOnce 等高级特性暂未支持，且部分接口受限于架构差异无法实现，详细信息请参考链接。

AutoMQ 复用了 Apache Kafka 的计算层代码，仅替换底层存储，因此可以做到和 Apache Kafka 对应版本功能完全兼容。 使用 Apache Kafka 的应用无需修改配置即可切换到 AutoMQ。更多兼容性细节请参考Apache Kafka 兼容性▸。

延迟：亚秒级 vs 毫秒级

WarpStream 使用 agent 组件转发消息到对象存储。由于访问 S3 需要根据 API 计费且存在百毫秒级的调用延迟，因此在消息写入的同步链路中进行批处理。这导致 WarpStream 的 P99 写入延迟超过 620ms，并且端到端延迟的 P99 达到 1.27s。

AutoMQ 利用块存储 EBS 作为消息写入链路的 WAL 缓存，实现消息写入到 EBS 后即返回响应结果，后台异步上传到对象存储，同时利用内存快速缓存热数据，实现毫秒级的消息读写延迟。

开放性：闭源 vs 源码可见

WarpStream 是一个商业闭源项目，提供兼容 Kafka 协议的服务。与之不同，AutoMQ 提供全托管的云服务和私有化部署选项，私有化部署可选择社区版本，社区版本提供源码。详细信息请参考授权许可证▸。

总结

虽然 AutoMQ 和 WarpStream 都使用了对象存储，但两者在架构设计上仍旧存在侧重点差异和不同的取舍。总结对比如下：

对比项	WarpStream	AutoMQ
架构	重写 Kafka 协议	对 Kafka 存储进行切面替换
兼容性	兼容 Apache Kafka 部分功能	复用 Kafka 计算层代码，兼容全部功能
延迟	400+ms 写入延迟，1s 级端到端延迟	< 10ms 级读写延迟
开放性	商业闭源	商业+源码可见