技术架构

Apache Kafka 诞生于 2011 年，面向传统的数据中心进行设计，以经典的 Shared Nothing 架构解决了横向扩展性问题，并逐渐演进至 Tiered Storage 架构以享受云存储带来的成本优势。到今天，AutoMQ 带来了一种更加纯粹的 Shared Storage 架构，能充分发挥出云原生的全部优势，相比较 Apache Kafka 有十倍的成本优势和百倍的运维效率提升。

Kafka 架构演进之路

Shared Nothing 架构

Shared Nothing 架构作为 Apache Kafka 最经典的架构，以存算一体的形式解决了传统数据中心环境下分布式存储软件的扩展性问题。Kafka 采用了一种基于 ISR[1] 的复制机制来提供数据的可靠性和系统的可用性。

随着云计算的逐渐成熟，催生了业务对弹性的需求，但经典的 Shared Nothing 架构无法满足这一诉求。Apache Kafka 的 Broker 节点在扩容时，需要复制大量的数据以完成分区的迁移，一般需要耗时数十个小时之久。

另一方面，Apache Kafka 需要进行三副本复制，用户在云上进行部署时，存储有两个选型：

选择云存储 EBS 作为 Broker 的存储介质，但价格高昂。EBS 自带的三副本机制叠加 ISR 复制会导致数据被存储 9 份，有极大的存储空间浪费。
选择本地磁盘作为 Broker 的存储介质，成本相对可控，但用户需要付出高昂的运维成本，上云的优势不复存在。

Tiered Storage 架构

当云计算逐渐成熟，规模越来越大，最先受益的是对象存储。对象存储低廉的存储成本，按量付费的产品形态，催生了一大批存储软件演进至 Tiered Storage 架构。

顾名思义，该架构添加了一层二级存储，数据在存储到一级存储后，会异步地将数据转移至二级存储。该架构能够在一定程度上将对象存储的成本优势利用起来，同时，缓解 Shared Nothing 架构的弹性问题。

但 Tiered Storage 架构并没有从根本上解决 Apache Kafka 的问题，主要原因有几个方面：

一级存储消耗的空间可以降低，但能降低多少因场景而异，还是需要进行严谨的容量评估，ISR 的复制带来的高昂的 EBS 成本也无法彻底解决。
无法快速扩缩容的问题依然存在，一级存储中的数据在扩容和缩容时都需要进行迁移复制，耗时可能从数十小时优化至了数小时。

简单来讲，Tiered Storage 架构中的一级存储相比较 Shared Nothing 架构并没有本质的变化，除了空间上有缩小外，文件系统上分区存储的布局以及 ISR 复制机制都没有发生变化。

Shared Storage 架构

AutoMQ 推出的 Shared Storage 架构彻底替换了 Apache Kafka 的存储层，创新性地将数据卸载到云存储上后，将 Broker 变得无状态。在该架构中：

数据以 Direct IO 的形式持久化写入到裸设备 EBS 中，然后被近实时地上传到对象存储中。
EBS 在该架构中作为共享的 WAL[2] 存储，仅用于 Recovery 链路，在空间上仅需要一块最小规格的 EBS 卷，比如 10 GiB。
EBS 往往被误解为本地磁盘，但实际上 EBS 是完全可以共享的云存储服务，AutoMQ 创新性地使用多重挂载[3] 和 NVMe 协议的 PR 锁[4] 机制将 EBS 用作共享的 WAL 存储。

AutoMQ 共享存储架构全景图

AutoMQ 推出的 Shared Storage 架构秉承了存算分离的架构理念，通过将存储分离至云服务，将计算变得完全无状态，使得整个架构易于弹性，并能充分发挥出云原生的优势。

共享存储层：AutoMQ 选择了云厂商规模最大的对象存储和 EBS 存储作为共享存储层的存储介质。其中，EBS 作为共享的 WAL 存储，对象存储作为数据的主存。
无状态计算层：AutoMQ 通过将 Apache Kafka 原生的 Log 存储替换为自研的流存储库——S3Stream，将 Broker 的存储卸载到云存储上，能同时撬动 EBS 的高性能、对象存储的低成本和高吞吐等特性。从而，使得计算层无状态。
控制层：AutoMQ 将存储状态完全卸载过后，非常易于实现秒级分区迁移，自动扩缩容，流量持续重平衡等特性。因此，AutoMQ 在内核中内置了一些 Controller 组件，比如 Auto Scaling 和 Auto Balancing 组件，分别负责集群的扩缩容以及流量的重平衡。