分布式文件系统中的文件缓存

文件缓存增强了 I/O 性能，因为以前读取的文件保存在主内存中。由于文件在本地可用，因此当重复请求这些文件时，网络传输将归零。文件系统的性能改进基于文件访问模式的局部性。缓存还有助于提高可靠性和可扩展性。

当今的大多数分布式文件系统都采用某种形式的缓存。文件缓存方案由许多标准决定，包括缓存数据粒度、缓存大小（大/小/固定/动态）、替换策略、缓存位置、修改传播机制和缓存验证。

缓存位置：文件可能保存在客户端或服务器的磁盘或主内存中，在具有内存和磁盘的客户端-服务器系统中。

服务器磁盘：它始终是保存文件的原始位置。这里有足够的空间以防文件被修改并变长。此外，该文件对所有客户端可见。

优点：不存在一致性问题，因为每个文件只有一个副本。当客户端要读取文件时，需要两次传输：从服务器的磁盘到主存，以及从客户端的主存到服务器的磁盘。

缺点：

这两种转移都可能需要一些时间。通过将文件缓存在服务器的主内存中以提高性能，可以避免一部分传输时间。
由于主内存有限，因此需要一种算法来确定应在缓存中维护哪些文件或文件的一部分。该算法将基于两个因素：缓存单元和缓存已满时应用的替换机制。

服务器的主内存：问题是当文件缓存在服务器的主内存中时，是缓存完整文件还是仅缓存磁盘块。如果缓存完整的文件，可以将其存储在连续的位置，并且高速传输会产生良好的性能。磁盘块缓存使缓存和磁盘空间更有效。
采用标准缓存技术来克服后一个问题。与内存引用相比，缓存引用非常少见。可以在 LRU（最近最少使用）中挑选最旧的块进行驱逐。如果磁盘上存在最新副本，则可以丢弃缓存副本。缓存数据也可以写入磁盘。客户端可以轻松透明地访问服务器主内存中的缓存文件。服务器可以轻松地使文件的磁盘和主内存副本保持一致。据客户称，系统中只存在一份文件副本。

客户端磁盘：数据也可以保存在客户端的硬盘上。尽管减少了网络传输，但在缓存命中的情况下，必须访问磁盘。因为在数据丢失或崩溃的情况下更改的数据将可用，因此该技术提高了可靠性。然后可以从客户端的硬盘驱动器中恢复信息。
即使客户端与服务器断开连接，文件仍然可以访问。由于可以在本地处理对磁盘的访问，因此无需联系服务器，这增强了可扩展性和可靠性。

好处：

由于在数据丢失的情况下可以恢复数据，因此可靠性增加。
客户端的磁盘具有比客户端的主内存大得多的存储容量。可以缓存更多数据，从而获得最高的缓存命中率。大多数分布式文件系统采用文件级数据传输架构，其中整个文件都被缓存。
由于可以在本地处理对磁盘的访问，因此可扩展性得到提高。

缺点：

唯一的缺点是磁盘缓存与无磁盘工作站不兼容。每个缓存都需要访问磁盘，从而导致响应时间显着增加。必须决定是缓存在服务器的主内存中还是在客户端的磁盘上。
尽管服务器缓存消除了对磁盘访问的需要，但仍然需要网络传输。在客户端缓存数据是减少网络传输时间的一种解决方案。系统应该使用客户端的主存还是磁盘，取决于系统是否需要节省空间或提高性能。
如果磁盘有更多空间，访问速度会很慢。服务器的主存储器可能能够比客户端的磁盘更快地提供文件。如果文件非常大，可以在客户端的磁盘上进行缓存。下图显示了最简单的方法，即避免缓存。

客户端的主内存：一旦同意将文件缓存在客户端的内存中，缓存就可以在用户进程的地址空间、内核或作为用户进程的缓存管理器中进行。
第二种选择是将文件缓存在每个用户进程的地址空间中，如下所示：

系统调用库负责缓存。文件在流程执行期间被打开、关闭、读取和写入。该库保存最常用的文件，以便在必要时可以重复使用。操作完成后，更新的文件将返回到服务器。当单个进程定期打开和关闭文件时，这种技术效果很好。
这对于数据库管理员来说很好，但对于在无法再次访问文件的情况下工作的程序员来说则不然。
该文件可以缓存在内核而不是用户的进程地址空间中，如图所示。然而，这种技术需要多次系统调用来访问每个缓存命中的文件。

可以使用单独的用户级缓存管理器来缓存文件。因此，内核不再需要维护文件系统代码，它变得更加孤立和灵活。内核可以在运行时决定为程序分配内存空间还是缓存。如果缓存管理器在虚拟内存中运行，内核可以将一些缓存文件存储在磁盘中，并且在缓存命中时将块带到主内存中。

优点：

这种技术更加隔离和灵活（因为内核不再需要维护文件系统代码）
当单个进程定期打开和关闭文件时，访问时间会减少。因此，性能增益是最大的。
允许无盘工作站。
有助于系统的可扩展性和可靠性。

缺点：

需要单独的用户级缓存管理器。
客户端缓存原则对虚拟内存没有价值，尽管缓存管理器可以锁定一些经常请求的页面。

缓存一致性 - 缓存更新策略：

当缓存位于客户端的节点上时，多个用户可以同时访问文件系统中的相同数据或文件。如果所有缓存都包含相同的最新数据，则认为它们是一致的。如果某些用户修改文件，数据可能会变得不一致。使用 DFS 的分布式系统必须保持其数据副本的一致性。
根据何时将更改传播到服务器以及如何验证缓存数据的真实性，提供了许多一致性策略。直写、关闭时写入和集中控制是三种类型。
当缓存位于客户端的节点上并且一个用户将数据写入缓存时，它也必须对其他用户可见。书面政策决定了何时执行写入。

有四种缓存更新策略：

Write-Through ：当新用户在此方法中编辑缓存条目时，它会立即写入服务器。任何需要来自服务器的文件的过程现在都将始终收到最新的信息。考虑以下场景：客户端进程读取文件，缓存它，然后退出进程。另一个客户端修改同一个文件，并稍后将更改发送到服务器。
如果在第一台机器上启动了一个进程，它带有文件的缓存副本，它将获得一个过时的副本。为了避免这种情况，比较两个副本的修改时间，客户端机器上的缓存副本和服务器上上传的副本，以与服务器验证文件。
延迟写入：为了减少持续的网络流量，定期将所有更新写入服务器或将它们一起批处理。它被称为“延迟写入”。此方法通过允许单个批量写入操作而不是多个微小写入来提高性能。在这种情况下，临时文件不会存储在文件服务器上。
关闭时写入：向前迈出的一步是仅在关闭文件后将文件写回服务器。 'Write on close' 是算法的名称。如果两个缓存文件背靠背写入，则第二个写入会覆盖第一个。这类似于两个进程在自己的地址空间中读取或写入，然后在单个 CPU 系统中写回服务器时发生的情况。
集中控制：出于跟踪目的，客户端将有关它刚刚打开的文件的信息发送到服务器，然后服务器执行读取、写入或两者兼有的活动。多个进程可以读取同一个文件，但是一旦一个进程打开文件进行写入，所有其他进程将被拒绝访问。服务器收到文件已关闭的通知后，会更新其表，只有这样其他用户才能访问该文件。

缓存验证方案：

当缓存的数据被修改时，修改传播策略会告知服务器节点上文件的主副本何时更新。它不提供有关何时更新其他节点缓存中的文件数据的信息。一个文件中的数据可能同时存储在多个节点的缓存中。
当另一个客户端更改与服务器上文件的主副本中的缓存项对应的数据时，客户端的缓存条目将变得过时。需要检查客户端节点缓存的数据是否与主副本匹配。如果不是这种情况，则必须使缓存的数据无效，并且必须从服务器请求新版本的数据。
要检查缓存数据的有效性，有两种方案：

客户端启动方法：客户端连接到服务器并验证其缓存中的数据是否与主副本一致。检查可以在不同的时间进行，因为-
- 每次访问前验证：因为这里每次访问时都必须调用服务器，这与缓存数据的实际目的背道而驰。
- 定期验证：按预定的定期间隔进行验证
- 验证文件的打开：打开文件时检查缓存条目。
服务器启动方法：当客户端打开一个文件时，它会通知文件服务器打开文件的目的——读、写或两者兼而有之。然后文件服务器的职责是跟踪哪个客户端正在处理哪个文件以及在哪种模式下工作。当服务器在各种客户端使用文件时发现任何不一致的可能性时，它会做出反应。
- 客户端将关闭以及在关闭文件时对文件所做的任何更改通知服务器。然后服务器更新其数据库以反映哪些客户端在哪些模式下打开了哪些文件。
- 服务器可以拒绝/排队请求，或通过请求所有打开文件的客户端将其从缓存中删除来禁用缓存，只要新客户端请求打开已经打开的文件并且服务器发现任何不一致之处/可能导致。