Fluss RoadMap 里 Zero Disk 是啥

本文在绿泡泡“狗哥琐话”首发于 2024.12.23 <-关注不走丢。

上期 Fluss 的内容还算受欢迎，这期加更，讲讲 Fluss RoadMap 里提到的 Zero Disks 是怎么个事儿。

所谓 Zero Disks 就是把所有的存储放在 S3 这种远程，容量无限的存储上。这样集群本身就可以做到无状态了。

那这玩意儿会怎么做呢？我们直接看一篇先成的文章。

原文链接：

https://medium.com/thedeephub/how-do-we-run-kafka-100-on-the-object-storage-521c6fec6341

这个 AutoMQ，就是 Kafka on S3 的实现。

AutoMQ 的目标是让 Kafka 不牺牲性能的情况下， 将所有消息都写入对象存储。从而提高 Kafka 的效率和弹性。

这里的不牺牲性能——应该说是“在绝大多数的场景”会比较严谨。

那接下来我们先来看一下 AutoMQ 的写入流程。

数据写进来的时候先进缓存（我们可以称为写缓存），然后呢，用 DirectIO 的方式把 WAL 写进硬盘（一般用 AWS 的 EBS），这个时候就会告知生产者写入成功了。在这之后会做一个异步的刷入到 S3。

DirectIO：绕过操作系统直接写文件系统缓存的实现，可以减少延迟并大幅提高性能，但是要写代码的人自己关注数据对齐、缓冲区等底层细节。

虽然 S3 和 EBS 都在远程，但是它们的写入时机是有很大的不同的。EBS 作为 WAL 的存储，肯定在最短时间内能够多攒数据就攒进去，然后刷到 EBS，这意味着它的先决条件是时间。这个可以理解，因为它刷数据越及时，需要恢复的时间也就越短。

而写到 S3 的数据则可以优先攒量，这样可以增加吞吐量。

接着我们来看一下读流程。

还是先走缓存，再走 S3。但有点不同的是，这里有个 Block Cache，这个缓存是在读的时候生成的。读取的时候会顺带一些预读。

这下我们知道了，AutoMQ 里有两个缓存：日志缓存处理写入和热读取（相当于最新数据的缓存），然后用块缓存进行冷读取（相当于历史数据的缓存）。

然后最后要说的是恢复。文章里写了个 case：

AutoMQ 集群有两个 broker A 和 B，每个代理都有两个关联的 EBS 存储。当其中一个一个 broker 挂掉的时候，会发生什么事情？

• 如前所述，一旦 broker 确认消息已进入 WAL （EBS），则认为消息已成功收到。

• 那么，如果 brokerA 崩溃了怎么办？该 brokerA 的 EBS 存储设备发生了什么情况？尚未写入对象存储的 EBS 数据如何？

• AutoMQ 利用 AWS EBS 多重挂载功能来处理这种情况。broker A 关闭后，EBS 设备 A 将连接到 broker  B。当 broker B 有两个 EBS 卷时，它将知道哪个卷是通过标签从空闲状态附加的。broker B 会将 EBS 存储 A 的数据刷新到 S3，然后删除该卷。此外，在将孤立 EBS 卷附加到 broker  B 时，AutoMQ 会利用 NVME 预留来防止数据意外写入此卷。这些策略可显著加快故障转移过程。

• 新创建的 broker 将具有新的 EBS 存储。

这里面使用到了 AWS 的一些机制，不过多重挂载一般公有云都是有的，所以 AutoMQ 也不是依赖于 AWS 实现的。