Apache Flink 的 blob 存储会将未使用的 blob 保留 30 分钟后清理

Apache Flink 的 BLOB 存储保存着运行中的集群不可或缺的二进制文件：用户上传用于运行作业的 JAR、在任务之间传递的超大消息，以及 Web UI 按需显示的 TaskManager 日志。在 1.4 版本之前，该存储存在三种故障模式，社区后来在 FLIP-19 中加以解决。同一个文件可能最终被存储多次。任何任务都不再需要的文件仍留在磁盘上。而且文件内容可能被修改而无人察觉。

这些问题都不会主动暴露。重复的 JAR 会悄无声息地浪费空间。孤立的 blob 只有在磁盘写满时才重要。损坏的文件会表现为作业失败，而这时写入它的进程早已结束。因此，这次重新设计无关吞吐量或延迟，而是关于已经跑偏的日常清理。

三个组件，三项职责

新设计将工作分为三部分，每一部分都有明确的职责范围。

组件	运行位置	职责
BlobServer	集中运行，服务于整个集群	通过本地副本加备份副本存储和提供 blob
BlobCache	在每个 TaskManager 上	服务本地读取，从 BlobServer 获取缺失文件，清理自己的存储
BlobClient	按请求运行	打开到 BlobServer 的连接，跟踪请求，确认交付

BlobServer 为所有内容保留两份副本：用于快速读取的本地存储和用于恢复的备份存储。文件按照固定路径约定存放：<path>/<jobId>/<BlobKey>，因此可以从位置读出 blob 所属作业和身份。上传先写入本地存储，然后同步到备份；这样设计是为了获得持久性，同时不让备份写入挡在调用方路径上。读取时先检查本地，仅在文件缺失时才去取备份。

BlobCache 运行在每个 TaskManager 上，并镜像相同的路径结构。它可以读取中央备份存储，但不能写入其中。当它需要自己没有的文件时，会向 BlobServer 请求传输。每个缓存自行决定何时清理不再需要的文件，从而将清理决策留给拥有磁盘的机器。

BlobClient 是请求方。它为每次上传或下载打开一条到 BlobServer 的专用连接，记录请求，并持续跟踪传输，直到确认文件已交付。

引用计数与删除前的有意停顿

在已知的最后一个读取者刚完成时就删除 blob，会让集群丢失另一个任务正要获取的文件。FLIP-19 用引用计数来应对：系统跟踪当前有多少任务持有某个文件，删除会等到计数归零。即便归零，文件也不会消失。它会保留一段可配置的间隔，在此期间若有新请求，它就会继续存活。

这个窗口是有代价的。每个被保留的 blob 都是集群无法用于其他用途的磁盘空间，而繁忙的集群会有意把文件留过其有用期限。默认值已朝着更快回收这些空间的方向调整：blob.retention.interval 现在默认是 30 分钟，低于此前的一小时。源材料没有给出缩短间隔能释放多少存储空间的数据，因此应把这个数字理解为一项设置，而不是一项结果。

不同文件受到不同处理，因此必须用单一间隔覆盖所有文件。

Blob 类型	用途	生命周期
JAR 文件	用户程序代码	与作业绑定；作业结束后清理
RPC 消息	任务之间的通信	短暂；使用后删除
日志文件	系统监控和 Web UI	按需存储，使用后清理

一次日志请求以缩微方式展示了这一模式。Web UI 请求 TaskManager 日志，TaskManager 将它们上传到 BlobServer，UI 再从那里下载并渲染。由于此后没有人需要该文件，它可以被清理掉，而不是保留。

大型消息也走同样的路径。发送方将负载写入 BlobServer，接收方下载它，消息处理完后引用计数下降。当每个接收方都确认后，该 blob 进入清理队列，等待其预定的清理轮次。

校验和与两层存储：保证止于何处

完整性保护是 FLIP-19 中在日常运行中最不常显现的部分，但一旦显现，也最能节省时间。系统在读取或复制文件时都会验证校验和，因此意外修改会以不匹配的形式暴露，而不是表现为一个小时后才失败、却没有明显原因的作业。结合先本地后备份的写入顺序，单块磁盘丢失不再意味着集群仍需要的 blob 就此消失。

这些保证值得与围绕它们的说法区分开来。校验和确认文件自写入以来未发生变化；源材料将验证描述为针对意外修改的保护，并未将其延伸到任何故意行为。镜像可防止副本损坏或缺失，但源材料没有说明两份副本是否会相互比较、在一次同步完成前本地存储能领先备份多少，或者当本地存储持有备份尚未见过的文件时，BlobServer 交接会如何处理。

最后一个空白很重要，因为 BlobServer 接管被描述为四步交接，而源材料没有列出这些步骤。重新设计背后的意图更容易确定：FLIP-19 旨在修复原始架构中的并发和清理问题，并为后续工作留出空间，包括大型 RPC 消息处理。具体实现把覆盖与未覆盖的界线画在哪里，取决于配置和代码，而不是一份概述。