Fluss RoadMap里Zero Disk是啥

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

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

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

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

原文链接：

这个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实现的。