- 提供低延迟、高性能的数据持久化写入。数据在写入 WAL 成功后即可返回确认给客户端。
- 当 Broker 节点出现故障需要 Failover 时，会从 WAL 中恢复未被及时上传到 S3 的数据。
WAL 存储实现
WAL 在实现上是一块固定大小的，循环写入的存储空间，存储介质可以有多种选型，但 WAL 实现上主要考虑以下几点：- 集中式写入，与 Apache Kafka 不同，AutoMQ 并不需要为每个分区写入不同的 Log 文件，通过将所有分区的数据混合写入到 WAL 中，能支持大规模分区情况下的高效写入。
- 顺序写入和组提交，数据顺序写入到 WAL 中，配合组提交机制，仅需少量的 IOPS 即可完成高吞吐写入。
- Direct IO 写入，数据直接写穿到存储介质上，充分利用云存储的持久性，写入成功后才可返回确认，不受操作系统 Page Cache 脏页回收等影响。
- 支持裸设备写入[1]，AutoMQ 仅需要写入一个文件，如果采用 EBS 作为存储介质，可以直接将 EBS 用做裸设备来写入，无需挂载文件系统，也没有文件系统带来额外的开销，性能和延迟是最优的。
WAL 存储介质选型
公有云厂商一般提供三种类型的存储服务，分别是：- 块存储，比如 AWS EBS，Azure Zone-redundant Disk[2]，GCP Regional Persistent Disk[3]，Alibaba Cloud Regional ESSD[4]。上述存储服务中 EBS 是单 AZ 多副本架构，其它几个块存储是多 AZ 的多副本架构，下文统称为 Regional EBS。
- 对象存储，是云厂商提供的最标准的存储服务，基本上各个云厂商都支持标准的 S3 协议。
- 文件存储，以 NFS 协议为主的文件存储服务，也广泛应用于大数据等业务场景，比如 AWS EFS[5] 和 AWS FSx 系列[6]。
| - | EBS & Regional EBS WAL | S3 WAL | NFS WAL |
|---|---|---|---|
| 多 AZ |
| S3 同时提供单 AZ 和多 AZ 的产品选型 | NFS 同时提供单 AZ 和多 AZ 的产品选型 |
| 持久性 | 5 个 9 到 9 个 9 之间 | 11 个 9 左右 | 11 个 9 左右 |
| 延迟 | 亚毫秒级 | 百毫秒级 | 毫秒级 |
| 成本 | 低 | 低 | 中 |
| 适用场景 | Regional EBS 为最佳选项，适用于所有的的 Kafka 业务场景 | 适用于大部分对延迟不敏感的场景，如日志，监控等场景 | AWS 上低延迟场景的解决方案，比如核心的交易撮合场景 |