CN104702700A - 一种邮件提取方法 - Google Patents

Abstract

本发明提供了一种邮件提取方法，该方法包括：在邮件服务器端设置访问目录；客户端使用标准的系统调用进行存取访问；客户端的事件驱动层接收系统调用请求；服务器端的事件处理层处理客户端的访问请求，与底层进行交互并根据请求类型作出处理；将应用请求发送至内核组件，触发客户端的事件驱动层，服务器端收到请求后将请求传送给事件处理层进行数据读写。本发明提出了一种邮件处理方法，减少客户端与服务器之间的交互次数；并对数据支持片段缓存，维护缓存的一致性；不依赖于底层邮件系统，具有良好的通用性；在网络不稳定时，继续向上层应用提供可靠的数据服务。

Description

一种邮件提取方法

技术领域

本发明涉及文件存储，特别涉及一种邮件提取方法。

背景技术

在这样的数据总量飞速增长的大背景下，数据中心、全球化的企业、云存储系统均要求能够有效并可靠的访问互联网分布的数据，例如用户的邮件可以存储在各个web集群服务器中。相比内网环境，互联网具有低带宽、高延时的显著特征，并且网络抖动和中断时有发生，这样便对文件的访问性能和可靠性带来挑战，难以向应用提供持续稳定的服务。基于网络的邮件系统在web服务器和客户端的每次“往返”过程都会对邮件的访问性能造成巨大的影响。当客户端访问某文件，向服务器发送open操作时，将打开文件的全部数据内容通过网络读取到客户端浏览器对应的网页目录，也就是说其只支持全文件的缓存方式，不支持部分文件数据的缓存。当客户端访问较大文件的一小部分数据时，不仅会造成带宽的严重浪费，而且在高延迟低带宽的网络环境下会严重影响数据的访问性能。

因此，针对相关技术中所存在的上述问题，目前尚未提出有效的解决方案。

发明内容

为解决上述现有技术所存在的问题，本发明提出了一种邮件提取方法，包括：

在邮件服务器端设置访问目录，使客户端获取与服务器端访问目录一致的目录视图；客户端对远程服务器端文件及目录使用标准的系统调用进行存取访问；

客户端的事件驱动层支撑相关的接口调用，接收系统调用请求，包括邮件系统创建、删除和数据读写；服务器端的事件处理层用于处理客户端的访问请求，与底层进行交互并根据请求类型作出处理；客户端和服务器端的数据传输层建立客户端和服务器之间的通信；

当应用请求到达客户端的文件系统层时，文件系统层继续将请求发送至内核组件，触发客户端的事件驱动层，然后通过数据传输层将请求远程发送给服务器端的数据传输层，服务器端收到请求后将请求传送给事件处理层进行数据读写。

优选地，所述客户端还包括缓存，用于缓存服务器邮件的配置数据信息和数据内容信息，所述数据内容信息包含与邮件对象对应的文件数据以及与目录对象对应的目录数据；

所述配置数据采用RAM缓存和数据库永久存储缓存相结合，RAM缓存为配置数据提供访问，将系统正在引用的配置数据缓存在RAM中，并且在RAM中维护配置数据的引用计数，当引用计数变为0时，就将配置数据从RAM中替换出去，并永久存储到数据库中；

对目录数据的存储采用数据库进行存储，对文件数据提供大容量的数据缓存，利用文件片段的数据缓存方式，其偏移量信息作为配置数据的一部分进行缓存，而偏移量所对应的实际数据内容则缓存在邮件系统中。

优选地，还包括：应用请求在到达内核模块后，被转换为配置数据请求或者数据内容请求，利用节点将请求与缓存联系起来，该节点与文件/目录一一对应，其包括所访问对象的配置数据以及数据内容信息，一旦获得节点就能访问相应对象的配置数据和文件数据；所述节点采用以下数据结构：

id：用于标识节点，是全局唯一的id值，由服务器端产生并维护；

attr：表示节点的属性信息；

cachetime：用于记录更新配置数据的系统时间；

lru：用于缓存容量管理中节点缓存数据的回收，所有被操作过的节点都会以LRU的方式组织成LRU链表，尾部的节点代表最久未被访问的对象；

extent：用于标识节点在缓存中缓存数据对应的数据片段，在读/写过程中将对应的片段信息链接到该extent链表上；

flush：用于表明该节点上的脏数据片段，在写过程中将写片段链接到该flush链表上，在刷新过程中访问该链表获取片段信息，并将对应的脏数据写回到服务器端；

cache_size：表示该节点的缓存数据大小；

data_state：代表该节点的缓存数据状态；

文件数据的缓存存在3种状态：清洁状态、脏状态以及锁定状态；所述清洁状态表明缓存数据与服务器端的源数据完全一致；所述脏状态表明客户端对缓存文件发生过写操作而没有将脏数据刷新到服务器端；所述锁定状态表明客户端正在将脏数据刷新到服务器端；

数据节点被创建时，节点处于清洁状态，此时对该节点执行读操作不会改变节点的状态，但对该节点执行写操作会使节点处于脏状态；当节点处于脏状态时，对该节点的读/写操作均不会修改节点的状态，但对该节点执行刷新操作时，则会使节点处于锁定状态；当节点处于锁定状态时，对该节点执行读操作不修改节点的状态，当刷新操作完成后并且在数据刷新期间没有被修改，则节点会变为清洁状态，否则节点会再次进入脏状态；上述刷新操作是指将客户端对数据的修改同步到服务器端的过程。

本发明相比现有技术，具有以下优点：

提出了一种邮件处理方法，减少客户端与服务器之间的交互次数；并对数据支持部分缓存，维护缓存的一致性；不依赖于底层邮件系统，具有良好的通用性；在网络不稳定时，继续向上层应用提供可靠的数据服务。

附图说明

图1是根据本发明实施例的邮件提取方法的流程图。

具体实施方式

下文与图示本发明原理的附图一起提供对本发明一个或者多个实施例的详细描述。结合这样的实施例描述本发明，但是本发明不限于任何实施例。本发明的范围仅由权利要求书限定，并且本发明涵盖诸多替代、修改和等同物。在下文描述中阐述诸多具体细节以便提供对本发明的透彻理解。出于示例的目的而提供这些细节，并且无这些具体细节中的一些或者所有细节也可以根据权利要求书实现本发明。

本发明的一方面提供了一种邮件提取方法。图1是根据本发明实施例的邮件提取方法流程图。邮件系统支持跨局域网数据访问，该系统是典型的B/S模式，包含一个客户端和一个服务器端。在服务器端仅需要设置访问目录后，在客户端就可以看到与服务器端访问目录一致的目录视图。在客户端可以像操作客户端邮件系统一样操作位于远程的邮件系统。客户端支持对远程(即服务器端)文件及目录使用标准的系统调用进行存取访问。

邮件系统的整体架构中，客户端的事件驱动层用于支撑相关的接口调用，接收邮件系统创建、删除、读、写等系统调用请求；服务器端的事件处理层主要用于处理客户端的访问请求，与底层进行交互并根据请求类型作出相应处理；而数据传输层分别存在于客户端和服务器端，用于客户端和服务器之间的通信。

邮件系统操作的处理过程包括：应用请求到达客户端的文件系统层，文件系统层继续将请求发送至内核组件，触发客户端的事件驱动层，之后通过数据传输层将请求远程发送给服务器端的数据传输层，服务器端收到请求后将请求传送给事件处理层，事件处理层与邮件系统交互，并完成对应请求，之后将请求所对应的响应沿着相反的方向传送给应用请求。至此，一个邮件系统的操作便完成。

为了给上层应用提供平稳的服务并避免由于远程的高时延和低带宽对服务性能带来的影响，将缓存设置于客户端，用于缓存服务器邮件的配置数据信息和数据内容信息。对上层应用来说，通过缓存访问服务器端数据就像访问客户端数据一样。

本发明提出的缓存策略支持对服务器端对象的配置数据以及数据进行缓存。而数据则分为两部分：与邮件对象对应的文件数据以及与目录对象对应的目录数据。在实际的应用中，配置数据的数据量比较少且空间占用相对固定；目录数据的数据量在基于目录的应用中将会比较大；文件数据的量与前两类数据相比一般会比较大。针对上述3种数据的不同特点，对3种数据采取不同的缓存方式。

配置数据采用RAM缓存和数据库永久存储缓存相结合的方案，RAM缓存为配置数据提供高效的访问。将系统正在引用的配置数据缓存在RAM中，并且在RAM中维护配置数据的引用计数，当引用计数变为0时，就将配置数据从RAM中替换出去，并永久存储到数据库中。

对目录数据的存储采用数据库进行永久存储，以利用数据库的查询性能提高目录数据的读取效率。

文件数据使用已有的邮件系统进行存储，由此提供大容量的数据缓存。为提升应用性能，降低缓存空间对邮件系统的占用并提供更高的灵活性，支持文件片段的数据缓存方式，其偏移量信息作为配置数据的一部分进行缓存，而偏移量所对应的实际数据内容则缓存在邮件系统中。

增加缓存后的邮件系统，上述应用请求的处理流程也发生了相应的变化。应用请求在到达内核模块后将被转换为配置数据请求或者数据内容请求。而将这些请求与缓存联系起来的重要数据结构就是节点，该节点与文件/目录是一一对应关系，其包括所访问对象的配置数据以及数据内容信息，一旦获得节点就能访问相应对象的配置数据和文件数据。以下对节点的主要成员作出相应的说明。

id：用于标识节点，全局唯一的id值，由服务器端产生并维护

attr：表示节点的属性信息

cachetime：用于记录更新配置数据的系统时间

lru：用于缓存容量管理中节点缓存数据的回收，系统中所有被操作过的节点都会以LRU的方式组织成一条LRU链表，尾部的节点代表最久未被访问的对象

extent：用于标识节点在缓存中缓存数据对应的数据片段，在读/写过程中将对应的片段信息链接到该extent链表上

flush：用于表明该节点上的脏数据片段，在写过程中将写片段链接到该flush链表上，在刷新过程中访问该链表获取片段信息，并将对应的脏数据写回到服务器端

cache_size：表示该节点的缓存数据大小

data_state：代表该节点的缓存数据状态

文件数据的缓存存在3种状态：清洁状态、脏状态以及锁定状态。清洁表明缓存数据与服务器端的源数据完全一致；脏表明客户端对缓存文件发生过写操作而没有将脏数据刷新到服务器端；锁定表明客户端正在将脏数据刷新到服务器端。数据节点被创建时，节点处于清洁状态，此时对该节点执行读操作不会改变节点的状态，但对该节点执行写操作会使节点处于脏状态。当节点处于脏状态时，对该节点的读/写操作均不会修改节点的状态，但对该节点执行刷新操作时，则会使节点处于锁定状态。当节点处于锁定状态时，表明此时正在执行刷新操作，过程中对该节点执行读操作将不会修改节点的状态，当刷新操作完成后并且在数据刷新期间没有被修改，则节点会变为清洁状态，否则节点会再次进入脏状态。上述过程中的刷新操作是指将客户端对数据的修改同步到服务器端的过程。

在邮件系统操作过程中，对配置数据有效性的判定采取超期策略，并且不需要服务器端参与缓存管理。在系统初始时设置配置数据的超期时间，在每次从服务器端获得配置数据信息时，记录当时的系统时间。当访问配置数据时，通过系统当前时间与从服务器端获得配置数据时记录的系统时间进行比较，如果两者的差值小于设定的超期时间，则认为配置数据有效，可直接从缓存中获取配置数据；否则认为配置数据失效，此时访问配置数据就需要重新从服务器端获得。

在web环境下，在首次访问服务器的数据时将数据缓存在客户端，如果在后续的过程中远程上的数据不发生改变，那就可以继续访问客户端的数据，以此来减少远程上的带宽消耗，并能够在网络不稳定或者发生故障时向上层应用提供平稳的服务。采取如下方式确定客户端缓存中数据内容的有效性：

如果其配置数据有效，则认为其缓存中的数据有效；如果其配置数据失效，待重新远程获得配置数据后，通过比较缓存中已失效配置数据的修改时间与新获得配置数据的修改时间是否相同进行判定，如果相同则认为缓存中数据内容有效；否则认为缓存中的数据已经失效，并将客户端缓存中的数据删除。

如果在客户端发生了写操作，那缓存的数据与服务器端的数据的一致性保证为最终一致性。在客户端的写过程直接将数据写到客户端本地缓存中，并将写片段的状态标记为脏，便可向上层应用返回写操作成功，这么做的好处是降低了高延迟低带宽所带来的性能损耗。也就是说在最终的某个时刻点，缓存的数据信息会与服务器端的数据信息一致。只要将数据写到客户端缓存写操作就能够将客户端对同一片段的多次“小写”合并成一次“大写”，这样能充分减少客户端与服务器端在远程上的交互次数，降低了高延迟带来的性能损耗，从而提高了写效率。这样的实现方式适用于远程上高并发流式文件写入的应用

为提高系统资源利用率，该缓存策略提供对缓存空间的阈值管理功能，在系统初始时设定缓存空间的上限阈值和下限阈值，并设计清理线程，该线程默认处于休眠状态，在系统运行过程中一旦检测到缓存容量达到设定的上限阈值，清理线程就被唤醒，释放已占用的缓存空间以保证缓存空间在设定的阈值范围内。

从服务器端读取数据或客户端执行写操作均将数据写入缓存，此时如果检测到已占用的缓存空间达到上限阈值，则会唤醒清理线程。该线程首先删除被替换到数据库中的对象所占用的数据缓存，如果此时剩余缓存空间达到下限阈值，则线程转入休眠状态；否则继续根据对象的访问时间，删除那些驻留在RAM中的对象对应的数据缓存，直到剩余缓存空间达到下限阈值，然后线程转入休眠状态。为加快删除缓存数据过程中邮件查找速度，替换到数据库中的对象按照访问时间从小到大排序，在RAM中对象则根据访问时间进行LRU排序。在删除缓存数据过程中，若存在脏数据，则需要先将对应的脏数据刷新到服务器端，再释放对应的缓存空间。

配置数据访问流程包括：客户端接收到应用程序的配置数据访问请求后，首先判断对应的配置数据在缓存中是否存在：1)若存在则判定其缓存的属性信息是否有效，判断的原则是：上次从服务器端获得配置数据所记录的系统时间与当前的系统时间之间的差值是否小于系统初始时设定的超期时间，若小于则说明缓存的配置数据有效，可直接使用缓存中的配置数据向上层应用请求返回；否则说明缓存的配置数据已经失效，此时需要重新从服务器端获得配置数据。2)若不存在，说明之前没有对该对象的配置数据访问过，此时需要从服务器端获得配置数据。

从服务器端获取到新的配置数据信息后，如果是第1次对该对象获取配置数据，则将配置数据直接进行缓存，并记录当前的系统时间。如果缓存中存有已经失效的配置数据时，则会对该配置数据对应的缓存数据进行有效性的判定，以此来保证缓存数据与服务器端源数据的一致性。

数据读取流程：客户端收到读请求后根据读请求的片段信息查询客户端缓存，确定对应的数据缓存是否存在，如果存在则直接从缓存中读取，否则需要从服务器端读取，读取后将对应的数据以及片段信息缓存在客户端，以便后续的读请求继续访问。本缓存策略支持片段数据缓存，每个片段都对应着<offset，size>二元组，其中offset代表文件数据在邮件中的偏移位置，size代表缓存中该片段的大小。在实际应用中，内核模块将读请求切分成最大128KB的读请求大小，将每次与服务器端交互的片段大小设定为1MB并将读取的数据缓存在客户端，并且实际应用访问多为顺序访问，那后续读请求就持续命中缓存，从而提升效率。

在刷新数据到服务器端的过程中，访问对应节点的flush链表，按照对应的片段信息读取客户端缓存中的脏数据，并将数据通过web写到服务器端，待该过程结束后，将节点的状态标识为清洁状态，表明此时该节点对应的缓存数据与服务器端源数据是一致的。

在上述邮件处理系统和方法的基础上，本发明在进一步的实施例中，采用数据去重技术进行备份数据的压缩，以取得更高的压缩率。只需要查询并读取对应的数据版本进行恢复，不需要额外的数据读取和运算，因此能够取得更低的备份成本和更快的恢复速度。由于不存在数据版本间的依赖关系，直接删除任意的数据版本而不会影响到其他的数据版本。针对公共网络环境下的数据安全和隐私保护问题，本发明支持对备份数据加密之后再存储到服务器端。

本实施例的邮件系统中，用户通过统一的数据传输层与邮件系统进行业务交互。在进行数据备份时，邮件系统将自身数据段驱动层的所有段写入请求都发送给数据传输层。把接收到的每一个请求都切分成若干个四元组<客户端编号，逻辑段号，时间点，数据段>，每个元组表示对某个段的一次写操作。在进行数据恢复时，客户端将恢复请求三元组<时间点，起始逻辑段号，结束逻辑段号>发送给数据传输层。如果客户端需要删除部分版本数据，则将一个删除请求二元组<起始时间点，结束时间点>发送给数据传输层，表示其需要删除的版本时间点范围。

本实施例的邮件系统中，进一步包含以下模块：

版本索引模块：系统为每个客户端都维护版本索引，保存该客户端所有段的所有版本信息，以便在恢复时快速查询。版本索引在逻辑上存储的是从二元组<逻辑段号，时间点>到数据段的映射关系。

由于产生的数据段版本数量巨大，无法使用数据库等普通工具来承载版本信息，因此本发明采用特定数据结构来实现版本信息的保存、更新和查询。即版本索引由存储在磁盘上的两级索引和在RAM中的缓存组成。磁盘索引定期进行更新操作，而RAM缓存则存储上次磁盘索引更新之后直至当前的新增的版本信息。

主索引由时间点和数据段组成。次索引包括逻辑段的版本信息在主索引中的起始位置，当前段最新版本的时间点和数据段ID。

RAM缓存使用一个散列表结构来存储若干对段号和指针，每个指针指向一个队列，表示上次磁盘索引更新后发生的对某个段的新写入信息。为了增强邮件系统鲁棒性，缓存内的信息被同步写入到一个磁盘日志中，以便系统重启之后可以恢复这些信息。

数据去重模块：该模块负责对每一个新的数据段使用hash算法计算其数据段ID，通过比对该ID判断此数据段是否与已有的数据段重复，进而进行去重。本发明采用统一的后端存储池，因此其数据去重是针对所有客户端的所有段版本数据进行的。

配置数据模块：该模块保存了所有数据段的配置数据信息，包括该数据段在服务器和客户端磁盘缓存中的引用计数；数据段在服务器和客户端磁盘缓存中的存储位置。

磁盘缓存模块：对每个客户端都在客户端磁盘缓存两类数据以加速恢复过程。第一类数据是所有段的最新版本数据段，第二类数据是客户端系统内最近若干次段写入操作的数据段。磁盘缓存使用段分配位图来管理存储空间，其段大小被设置成所有客户端系统段大小的最小值，每个数据段在磁盘上连续存储，这样其存储位置就可用其起始段号来表示。

RAM缓存模块：采用LRU算法在RAM中缓存一定数量的去重数据段，从而进一步减少从服务器或磁盘读取的需要，以加速恢复过程。

在数据备份模式下，本发明的数据备份流程：

数据传输层持续从客户端系统接收数据写操作流，并分割成针对单个段的写操作。每个写操作的数据段都被传递给数据去重模块计算出数据段进行去重。

在索引更新粒度上采用定期更新策略。在每次索引更新时，本发明读取当前的主索引，将RAM缓存内每个段的新版本记录追加到该段的主索引记录区末尾，从而生成一个全新的主索引。此过程是从原索引顺序读取数据，并顺序写出数据到新索引，可以达到很快的更新速度。次索引是一个固定长度的结构，可以在新的主索引生成之后进行原地更新，其更新操作也是从头至尾一次性顺序完成，同样具有极高的更新速度。在索引更新开始前，一个新的RAM缓存会被生成，以容纳新到的记录，而原缓存则在更新操作完成之后被释放。

根据数据去重模块的结果更新配置数据信息，对新的数据段建立新的元组并赋初始值，对重复的数据段则更新其引用计数。

每一个新的写操作信息还会被传递给磁盘缓存模块，只有磁盘缓存内尚不存在的数据段才会被写入磁盘。根据缓存数据的定义，原数据将被新数据逐步替换，各数据段在磁盘缓存中的位置和引用计数信息则被同步更新。

从去重模块得到所有的去重并批量存储到服务器端，同时将其服务器端位置信息进行更新。至此即完成了一次对新到写操作的记录和备份过程。

数据恢复流程具体为：

当数据传输层从客户端系统接收到一个数据恢复请求时，它将启动数据恢复进程。首先启动若干工作线程，包括一个版本查询线程、多个数据读取线程和一个数据重组线程。

对于每个数据段，版本査询线程从版本索引中査找到时间点不晚于待恢复时间点的最新的版本信息。对于每个段号，该线程首先査询RAM缓存，如能查到结果则直接返回，否则査询线程从次索引中读取该段的信息。如果时间点满足条件，则直接返回数据段，否则继续在主索引中，根据当前段和下一段表示的起止位置，采用折半搜索算法査找到满足条件的结果。两级磁盘索引都是由定长元素构成的数组，因此对其元素的定位和查找较快。

查找到的每个段的待恢复版本的数据段都会被传递给数据读取线程和数据重组线程。数据重组线程在RAM中维护一个队列结构作为滑动窗口，每个队列元素依次表示一个连续待恢复区域内的某个段。对于某个需读取的数据段ID，重组线程首先检查RAM缓存，如果缓存命中则直接读取，否则查找其配置数据信息，如果其客户端磁盘缓存引用计数大于0，则根据磁盘缓存位置从磁盘读取，否则根据服务器端存储位置从服务器端读取。读取操作由数据读取线程并发执行。对于每个读取到的数据段，重组线程将其数据复制到当前滑动窗口内所有其出现的位置。随后，滑动窗口前部已读取的数据段被批量传输给客户端系统供其写入，恢复窗口则继续向后滑动，直至完成所有段的恢复操作。

版本删除流程具体包括：

如果客户端需要删除部分版本数据，则可将起始时间点，和结束时间点发迭给数据传输层，表示其需要删除的版本时间点范围。读取旧版本索引，去除这些版本记录，生成新版本索引。每一个被删除版本包含的数据段ID则被传递给配置数据模块，对其引用计数减1。邮件系统还采用后台垃圾回收进程来定期检査各个数据段ID的服务器端引用计数，当其变成0时，则将相应数据从服务器端批量删除，以减少存储成本。

综上所述，本发明提出了一种邮件处理方法，减少客户端与服务器之间的交互次数；并对数据支持片段缓存，维护缓存的一致性；不依赖于底层邮件系统，具有良好的通用性；在网络不稳定时，继续向上层应用提供可靠的数据服务。

显然，本领域的技术人员应该理解，上述的本发明的各模块或各步骤可以用通用的计算系统来实现，它们可以集中在单个的计算系统上，或者分布在多个计算系统所组成的网络上，可选地，它们可以用计算系统可执行的程序代码来实现，从而，可以将它们存储在存储系统中由计算系统来执行。这样，本发明不限制于任何特定的硬件和软件结合。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

Claims (3)

1.一种邮件提取方法，其特征在于，包括：

在邮件服务器端设置访问目录，使客户端获取与服务器端访问目录一致的目录视图；客户端对远程服务器端文件及目录使用标准的系统调用进行存取访问；

客户端的事件驱动层支撑相关的接口调用，接收系统调用请求，包括邮件系统创建、删除和数据读写；服务器端的事件处理层用于处理客户端的访问请求，与底层进行交互并根据请求类型作出处理；客户端和服务器端的数据传输层建立客户端和服务器之间的通信；

当应用请求到达客户端的文件系统层时，文件系统层继续将请求发送至内核组件，触发客户端的事件驱动层，然后通过数据传输层将请求远程发送给服务器端的数据传输层，服务器端收到请求后将请求传送给事件处理层进行数据读写。

2.根据权利要求1所述的方法，其特征在于，所述客户端还包括缓存，用于缓存服务器邮件的配置数据信息和数据内容信息，所述数据内容信息包含与邮件对象对应的文件数据以及与目录对象对应的目录数据；

所述配置数据采用RAM缓存和数据库永久存储缓存相结合，RAM缓存为配置数据提供访问，将系统正在引用的配置数据缓存在RAM中，并且在RAM中维护配置数据的引用计数，当引用计数变为0时，就将配置数据从RAM中替换出去，并永久存储到数据库中；

对目录数据的存储采用数据库进行存储，对文件数据提供大容量的数据缓存，利用文件片段的数据缓存方式，其偏移量信息作为配置数据的一部分进行缓存，而偏移量所对应的实际数据内容则缓存在邮件系统中。

3.根据权利要求2所述的方法，其特征在于，还包括：应用请求在到达内核模块后，被转换为配置数据请求或者数据内容请求，利用节点将请求与缓存联系起来，该节点与文件/目录一一对应，其包括所访问对象的配置数据以及数据内容信息，一旦获得节点就能访问相应对象的配置数据和文件数据；所述节点采用以下数据结构：

id：用于标识节点，是全局唯一的id值，由服务器端产生并维护；

attr：表示节点的属性信息；

cachetime：用于记录更新配置数据的系统时间；

lru：用于缓存容量管理中节点缓存数据的回收，所有被操作过的节点都会以LRU的方式组织成LRU链表，尾部的节点代表最久未被访问的对象；

extent：用于标识节点在缓存中缓存数据对应的数据片段，在读/写过程中将对应的片段信息链接到该extent链表上；

flush：用于表明该节点上的脏数据片段，在写过程中将写片段链接到该flush链表上，在刷新过程中访问该链表获取片段信息，并将对应的脏数据写回到服务器端；

cache_size：表示该节点的缓存数据大小；

data_state：代表该节点的缓存数据状态；

文件数据的缓存存在3种状态：清洁状态、脏状态以及锁定状态；所述清洁状态表明缓存数据与服务器端的源数据完全一致；所述脏状态表明客户端对缓存文件发生过写操作而没有将脏数据刷新到服务器端；所述锁定状态表明客户端正在将脏数据刷新到服务器端；

数据节点被创建时，节点处于清洁状态，此时对该节点执行读操作不会改变节点的状态，但对该节点执行写操作会使节点处于脏状态；当节点处于脏状态时，对该节点的读/写操作均不会修改节点的状态，但对该节点执行刷新操作时，则会使节点处于锁定状态；当节点处于锁定状态时，对该节点执行读操作不修改节点的状态，当刷新操作完成后并且在数据刷新期间没有被修改，则节点会变为清洁状态，否则节点会再次进入脏状态；上述刷新操作是指将客户端对数据的修改同步到服务器端的过程。