CloudFS 数据湖模式的工作原理是利用高速存储介质对TOS提供读写加速能力，在元数据服务中会挂载 TOS Bucket ，将 CloudFS 与 TOS 的元数据映射起来，提供统一的元数据视图和命名空间。

元数据一致性

CloudFS提供统一元数据视图，从CloudFS 可以读取到最新的TOS 数据，而非老版本的数据，那么认为数据是一致的。什么情况下需要关注元数据一致性呢？这主要和用户数据的写入姿势相关。写加速是CloudFS的一个核心特性，目前主要使用场景是利用写加速，数据直接写入CloudFS，然后异步刷写到TOS中，这时不需要关注元数据一致性，因为总是能读到最新数据，这也是最推荐的使用方法。某些情况下，需要绕过CloudFS 直接写入TOS且需要使用读加速能力，对于这些文件或目录，无法读到最新数据，这时需要关注元数据一致性。

解决方案

CloudFS 经过大量的实践，根据使用场景针对元数据一致性提供了不同的解决方案。

消费TOS 事件同步元数据

当存在绕过CloudFS 写入TOS的情况，CloudFS 可以消费TOS 元数据变更事件保持元数据一致。需要考虑的是如果同步一个TOS Bucket 所有数据事件，会把不需要加速或不需要（直写CloudFS）同步的目录或文件同步到CloudFS，这样会产生大量对TOS 的无效检查请求，耗用其元数据QPS 配额，所以如果绕过CloudFS写入TOS数据集中在若干目录，推荐使用该方案配置对应目录前缀的事件同步， 如需开启请联系火山引擎同学了解。

元数据加载

当存在绕过CloudFS 写入TOS的情况，可以通过CLI 将TOS 元数据主动加载到CloudFS中以获取最新的数据。需注意CloudFS 消费 TOS 事件，只能消费到开启同步功能时间点后的增量事件，所以如果TOS Bucket 在挂载进CloudFS前已经存在数据，需要主动将存量元数据加载到CloudFS中。详细参见文档 https://www.volcengine.com/docs/6720/1158286。

基于时间戳自动刷新元数据

CloudFS 也支持基于时间戳的自动刷新元数据能力，默认是关闭的，通过一个客户端配置（ cfs.filesystem.sync-interval 元数据同步间隔） 打开元数据自动刷新功能。有几种不同的配置方式：

• 配置为-1 （默认），对于一个路径的元数据访问请求，仅仅在路径不存在的情况下，会触发元数据同步，将元数据加载到CloudFS中（如图对应流程1），后续的访问，就不会再触发新的同步了（如图对应流程4）。
• 配置为大于0，如30则代表在元数据访问时，会对比路径或父路径的最近一次加载时间，和本次访问的时间间隔是否在30秒内，如果满足条件则认为元数据依旧生效未过期无需刷新，否则需要重新同步元数据（如图对应流程3 和 5）。