WAL 存储

在流存储库 S3Stream 中，WAL 是核心组件之一，其主要有两个用途：

提供低延迟、高性能的数据持久化写入。数据在写入 WAL 成功后即可返回确认给客户端。
当 Broker 节点出现故障需要 Failover 时，会从 WAL 中恢复未被及时上传到 S3 的数据。

WAL 并不承担常规的数据消费职责，所以 WAL 组件对存储介质的 IOPS 要求并不高，更多地关注成本、延迟和吞吐三个关键指标。

在不同的运行环境，AutoMQ 提供了多种存储介质的 WAL 实现，包括 EBS WAL、Regional EBS WAL、S3 WAL 等。

EBS WAL

云厂商提供的块存储服务 EBS 是用来实现 WAL 的最佳存储介质，其有以下几个特征：

低延迟，一般提供亚毫秒级的 IO 延迟，甚至更低，能够满足 Kafka 所有的业务场景对延迟的要求。
内置多副本机制，提供足够高的数据持久性，一般在 5 个 9 左右，十分契合 AutoMQ 持久性分离的理念，也是 AutoMQ 不需要实现额外的多副本机制的基础。
低成本，S3Stream 对 WAL 盘仅需要数 GiB 的空间，一块 10GiB 的 EBS 就能提供 120MiB/s 左右的吞吐和 3000 左右的 IOPS，但成本每月仅需要几块钱。

S3Stream 的 WAL 存储是面向写入吞吐和延迟来优化[1]，有以下几个写入特征：

集中式写入，与 Apache Kafka 不同，AutoMQ 并不需要为每个分区写入不同的 Log 文件，通过将所有分区的数据混合写入到 WAL 中，能支持大规模分区情况下的高效写入。
裸设备写入，AutoMQ 仅需要写入一个文件，可以直接将 EBS 用做裸设备来写入，无需挂载文件系统，也没有文件系统带来额外的开销，性能和延迟是最优的。
顺序写入和组提交，数据顺序写入到 WAL 中，配合组提交机制，仅需少量的 IOPS 即可完成高吞吐写入。
Direct IO 写入，AutoMQ 旁路了内核的 Page Cache，数据直接写穿到 EBS 上，写入成功后即可返回确认，不受 Page Cache 脏页回收等影响。该特性也是 AutoMQ 具备稳定的低延时表现的基础。

Regional EBS WAL

EBS 虽然内置了多副本机制，但这些副本往往都分布在同一个可用区内，意味着如果出现可用区级的故障，在 WAL 上的少量数据可能有无法恢复的风险。

幸运的是，越来越多的云厂商，比如 Azure[2]、GCP[3] 以及阿里云[4]，都开始提供 Regional EBS 的产品形态，该产品的多个副本一般分布在三个可用区内，提供了足够高的数据持久性和可用性。

使用 Regional EBS 作为 S3Stream 的 WAL 实现，避免了 AutoMQ 在可用区间进行数据的复制，从而能节省大量的跨可用区流量费。

S3 WAL

AutoMQ 除了可以采用各种 EBS 存储介质作为 WAL 存储之外，还可以使用对象存储的 API 来实现 WAL。采用 S3 WAL 可以完全消除对 EBS 的依赖，整个架构变为直接基于 S3 的架构，有以下优势：

依赖项减少，运维足够简单。
不同云厂商托管的存储服务有差异，在 EBS 能力不足的云厂商上部署 AutoMQ 时可以采用 S3 WAL。
很多私有云场景，可能仅有 S3 的实现，采用 S3 WAL，使 AutoMQ 更具有普适性。

但 S3 WAL 的缺点也比较明显：

S3 WAL 延迟较高，达数百毫秒级，适用于日志、可观测、离线计算等业务场景。
相较于 EBS WAL，写 S3 WAL 会额外消耗一份网络出口带宽，使得 Broker 节点能承担的峰值读写流量会相应降低，从而使整体成本上升。

S3 WAL 的 AutoMQ 形态，特别适合能容忍百毫秒级别延迟的业务，能够充分享受到更简洁的共享存储架构。

S3 Express WAL

虽然一般的对象存储服务延迟都较高，但部分云厂商提供低延迟的 S3 产品形态，比如 AWS 提供了 S3 Express One Zone[5]，Azure 提供了 Premium Blob Storage[6]，它们均能实现个位数毫秒的延迟，能够满足 Kafka 低延迟的业务诉求。

另外，对于自建对象存储，如 MinIO 的场景，可以通过配置高速的存储介质，也能提供低延迟的对象存储部署。

当环境中提供低延迟的 S3 实现时，AutoMQ 完全可以采用 S3 WAL 的形态，来去除对 EBS 的依赖，使整个架构更加简洁，同时能满足业务低延迟的诉求。

多 WAL

在 S3Stream 的 WAL 存储实现当中，已经通过了多线程技术来大幅度提高 IO 队列深度，能够基于单 WAL 达到 GiB 级的带宽写入。

但为了降低 EBS 成本，AutoMQ 推荐使用小盘作为 WAL 存储，这是因为云厂商为一块最低规格的 WAL 盘也提供 120MiB/s 的吞吐，但如果想获得额外的吞吐量，需要购买额外的 EBS 容量。以阿里云为例，两块 20GiB 的 PL1 ESSD[7]，能提供 260MiB/s 的带宽，月成本 40 块。但如果仅使用一块 ESSD，需要 280GiB 的存储空间才能获得同样的吞吐，成本有 7 倍的差异。

所以，通过组合多块小盘形成多 WAL 解决方案，是在公共云上成本最优的方案，这样能低成本地提高单节点的吞吐上限，从而将超大规模的 AutoMQ 集群的节点数控制在一定的范围内。

另外，鉴于 AWS 的 S3 Express 和 EBS 云存储均只能分布在单个可用区内，AutoMQ 也支持组合 EBS WAL 和 S3 Express WAL 在 AWS 上提供低延迟的、多可用区的和低成本的架构。