CN117950597A - 数据修改写方法、数据修改写装置以及计算机存储介质 - Google Patents

Abstract

本申请提出一种数据修改写方法、数据修改写装置以及计算机存储介质。数据修改写方法包括：响应于文件修改写指令，客户端服务通过元数据节点打开对象文件；客户端服务基于文件修改写指令指定的偏移和修改长度，定位到对象文件的逻辑偏移位置；客户端服务将修改写数据写入多个数据分片中，并将数据分片发送到对应的数据节点将数据分片进行缓存，并返回预修改结果；在预修改结果满足预设条件时，客户端服务向数据节点发送二阶段提交请求；数据节点根据二阶段提交请求将缓存的数据分片写入对象文件。本申请的数据修改写方法，通过二阶段提交模型，减小提交阶段各种异常导致的数据不一致窗口期，达到提高数据一致性的目的。

Description

数据修改写方法、数据修改写装置以及计算机存储介质

技术领域

本申请涉及分布式存储技术领域，特别是涉及一种数据修改写方法、数据修改写装置以及计算机存储介质。

背景技术

分布式对象存储系统，首先是一套分布式系统，解决了单机系统存储空间受限、容易出现单点故障、不易规模化扩展的痛点。对象存储主要特点是实现了控制通路（代表信令流的元数据）和数据通路（真实数据的读写）的分离，并基于对象存储设备，每个对象存储设备也具有一定的智能属性，能够智能管理其上的数据分布，所构建出的一套新的网络存储架构。

修改写在本地文件系统层面是一个非常普遍的操作，应用场景包括对本地文本文件、word、excel等反复修改，因本地文件系统不涉及分布式一致性和分布式节点的数据同步，修改写实现起来非常简单，但要在分布式存储层面实现修改写功能，二者的复杂程度就不在一个量级了。

业界分布式存储系统基本都无法支持文件随机修改写（读改写），通常仅支持追加写（append）操作；如，HDFS（Hadoop Distributed File System，Hadoop分布式文件系统），修改写可能涉及多个副本的修改，复杂度和实现成本高，因此其设计之初就不支持修改写，通过上传新文件，并删除老文件实现文件的修改功能，无法支持文件的原地修改写。JuiceFS（开源的分布式文件系统）底层也通过对象存储实现数据存储，通过自己实现一个元数据索引的管理，支持修改写方案时，并未真正修改底层对象，仅通过修改元数据索引，标记过期对象为无效数据，后续删除，本质还是重新上传新对象来实现随机修改写。

发明内容

为解决上述技术问题，本申请提出了一种数据修改写方法、数据修改写装置以及计算机存储介质。

为解决上述技术问题，本申请提出了一种数据修改写方法，所述数据修改写方法应用于一种分布式存储系统，其中，所述分布式存储系统包括客户端服务、元数据节点以及数据节点，所述数据修改写方法包括：

响应于文件修改写指令，所述客户端服务通过所述元数据节点打开对象文件；

所述客户端服务基于所述文件修改写指令指定的偏移和修改长度，定位到所述对象文件的逻辑偏移位置；

所述客户端服务将修改写数据写入所述多个数据分片中，并将所述数据分片发送到对应的数据节点

所述数据节点将所述数据分片进行缓存，并返回预修改结果；

在所述预修改结果满足预设条件时，所述客户端服务向所述数据节点发送二阶段提交请求；

所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件。

其中，所述客户端服务将修改写数据写入所述多个数据分片中，包括：

所述客户端服务将所述修改写数据在内部条带缓存进行修改，获取条带缓存数据；

所述客户端服务根据所述条带缓存数据，计算校验块数据；

所述客户端服务将所述修改写数据以及所述校验块数据写入所述多个数据分片中。

其中，所述数据节点将所述数据分片进行缓存，并返回预修改结果之后，所述数据修改写方法还包括：

在所述预修改结果不满足预设条件时，所述客户端服务向所述数据节点发送回退请求；

在所述预修改结果满足预设条件时，所述客户端服务向返回预修改成功结果的数据节点发送二阶段提交请求。

其中，所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件之后，所述数据修改写方法还包括：

所述客户端服务获取所述数据节点的二阶段修改结果，并将所述二阶段修改结果为失败的数据块上报到所述元数据节点；

所述元数据节点判断所述数据块为可恢复状态时，则进行文件智能恢复。

其中，所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件之后，所述数据修改写方法还包括：

所述数据节点对存储的数据块进行周期性循环冗余校验，获取数据块状态；

在所述数据块状态为异常时，所述数据节点将对应的数据块信息上报到所述元数据节点，以使所述元数据节点进行文件状态更新或文件数据恢复。

其中，所述数据修改写方法，还包括：

响应于数据读取请求，所述客户端服务创建文件读句柄；

所述客户端服务判断是否存在文件写句柄；

若是，所述客户端服务将所述文件读句柄指向所述文件写句柄的数据缓冲区，将所述数据缓冲区的最新数据与已读磁盘数据合并，返回最新的读取数据。

其中，所述客户端服务将所述文件读句柄指向所述文件写句柄的数据缓冲区之后，所述数据修改写方法包括：

所述客户端服务获取各数据节点的数据缓冲区的最新分片数据及其事务标识号；

所述客户端服务判断所述各数据节点的事务标识号是否一致；

若是，所述客户端服务将所述个数据节点的最新分片数据进行合并，得到所述数据缓冲区的最新数据。

其中，用户通过用户态文件系统访问所述分布式存储系统，其中，所述用户态文件系统包括内核模块、用户态以及挂载工具。

其中，所述分布式存储系统通过键值对存储模块维护目录管理结构，其中，所述目录管理结构包括根目录以及用户目录，所述用户目录为分桶表。

其中，所述分桶表内存储有大文件表和/或小文件表，其中，所述大文件表存储逻辑大文件属性信息，所述小文件表存储逻辑小文件属性信息，以及小文件与大文件的映射关系；其中，同一分桶表的小文件写入同一逻辑大文件。

为解决上述技术问题，本申请还提出一种数据修改写装置，所述数据修改写装置包括存储器以及与所述存储器耦接的处理器；其中，所述存储器用于存储程序数据，所述处理器用于执行所述程序数据以实现如上述的数据修改写方法。

为解决上述技术问题，本申请还提出一种计算机存储介质，所述计算机存储介质用于存储程序数据，所述程序数据在被计算机执行时，用以实现上述的数据修改写方法。

与现有技术相比，本申请的有益效果是：响应于文件修改写指令，所述客户端服务通过所述元数据节点打开对象文件；所述客户端服务基于所述文件修改写指令指定的偏移和修改长度，定位到所述对象文件的逻辑偏移位置；所述客户端服务将修改写数据写入所述多个数据分片中，并将所述数据分片发送到对应的数据节点所述数据节点将所述数据分片进行缓存，并返回预修改结果；在所述预修改结果满足预设条件时，所述客户端服务向所述数据节点发送二阶段提交请求；所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件。本申请的数据修改写方法，通过二阶段提交模型，减小提交阶段各种异常导致的数据不一致窗口期，达到提高数据一致性的目的。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是本申请提供的分布式存储系统的结构示意图；

图2是本申请提供的目录管理结构一实施例的示意图；

图3是本申请提供的数据修改写方法一实施例的流程示意图；

图4是本申请提供的两阶段修改写的流程示意图；

图5是本申请提供的两阶段修改过程的异常处理的逻辑示意图；

图6是本申请提供的数据修改写方法另一实施例的流程示意图；

图7是本申请提供的数据读取流程的示意图；

图8是本申请提供的数据节点返回数据一实施例的示意图；

图9是本申请提供的用户态文件系统的工作流程示意图；

图10是本申请提供的数据修改写装置一实施例的结构示意图；

图11是本申请提供的计算机存储介质一实施例的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请应用于分布式对象存储领域，底层通过对视图文件聚合存储与两阶段提交模型的设计和对象写事务隔离等技术，结合用户态文件系统Fuse（Filesystem inUserspace），通过NFS（网络文件系统，Network File System）协议对外提供标准文件存储能力，解决了传统分布式存储不支持修改写的问题。对图片等海量小文件的存储通过KV存储的引入与逻辑大文件聚合技术，提升分布式存储系统海量小文件存储规模。

本申请所涉及的技术术语具体如下：

云存储系统：本申请所涉及的云存储系统是一种分布式的数据存储系统，由1至多台元数据服务器和数据节点服务器组成；存储文件的元数据和真实数据分离，真实数据分片存储，采用纠删码Erasure Code实现冗余和容错。

元数据节点/服务：保存和管理元数据的节点/服务，MetaDataServer，以下简称MDS。

数据节点：真实文件数据存储的服务器节点，DataNode，以下简称DN。

纠删码：Erasure Code，简称EC。

strip：条带，即一定长度的原始数据，由N+M个piece组成。

piece：数据分片，一定长度的原始数据按照指定EC规则，切分为N个原始数据块，每个数据块称为一个piece。

原始数据块：原始数据分片后的每一个分片称为原始数据块。

本申请要解决的问题是：在视频安防领域视图存储场景，结合视图数据的特点，视频数据为连续流式大文件、图片为小文件，其中视频占用存储空间大，图片占用的元数据资源多，如何在一套分布式存储系统，以标准的文件Posix接口（可移植操作系统接口，Portable Operating System Interface of UNIX）实现视图数据的存储，现有成熟方案无法很好的解决。

本申请的分布式存储系统应用于视图存储领域，基于标准的文件接口设计与实现，在云存储系统中支持对文件级别任意位置数据进行修改写，使修改写像本地文件系统中一样简单，且提供提高一致性的解决方法，规避修改写过程的数据不一致风险。

本申请还支持其他标准的Posix接口，如truncate操作，支持对标准文件的截取命令，支持truncate变大和变小等操作。本申请还通过底层进行逻辑大文件的合并技术，提升图片等小文件的存储规模，显著降低分布式文件系统元数据的管理压力。本申请主要通过上述两个主要的优化和设计对外基于NFS协议提供标准的文件存储能力。

具体地，本申请涉及的分布式对象存储系统结构请参阅图1，图1是本申请提供的分布式存储系统的结构示意图。

如图1所示，分布式存储系统的主要模块作用简介如下。客户端（SDK，SoftwareDevelopment Kit）：所有用户写入操作云存储请求的入口；元数据管理节点（MDS）：响应整个云存储系统的元数据请求，内部维护整个系统元数据镜像，同时负责存储节点（Datanode）的管理与负载均衡，以及其他系统相关的管理工作；数据节点（Datanode）：相对管理节点实现元数据管理，数据节点提供真实业务数据的写入与存储能力，对外提供接口SDK将数据写入持久化存储介质，周期性向管理节点上报数据块状态已维系存储系统文件状态等。

需要说明的是，本申请的SDK客户端服务，一般封装成云存储客户端模块，或者客户端服务，在后续的描述中，通过SDK模块进行说明。

基于图1所示系统对象存储的特点，本申请的分布式存储系统实现了管理数据信令流与数据流的分离，图1展示了两种数据流的交互流程。

本申请针对分布式存储系统主要提出四个核心部分，分别是1、元数据与目录管理；2、数据写入流程；3、数据读取流程；4、NFS卷共享。

关于第一核心部分：元数据与目录管理中的元数据管理的具体内容如下：

为提升云存储元数据管理规模，解决百亿级文件的存储、查询功能，本申请的分布式文件存储系统通过外置KV（Key-Value，键值对存储）存储服务集群+云存储内部逻辑小文件聚合存储技术实现元数据管理能力的提升。

KV存储服务，核心是通过几张元数据表结构，即大文件表、小文件表以及bucket表的设计，满足正常小文件的写入、读取、删除等操作。其中，大文件表：存储逻辑大文件属性信息；小文件表：存储小文件属性信息，以及小文件与大文件的映射关系；bucket表（分桶表）：存储目录的信息。

下面分别对三个关键步骤元数据的变化进行可行性描述：

1)文件写入：

默认用户挂载根目录，用户创建的一级目录映射为云存储系统的bucket，相同bucket内的小文件写入同一个逻辑大文件。

创建小文件，KV存储服务记录元数据索引。

写入数据，获取bucket对应逻辑大文件的写句柄，写入数据，同时更新KV文件索引表，新增或者修改大文件表，并且在KV记录大文件的使用情况。

2)文件读取：

指定文件名，元数据服务查询KV，获取对应的EFS(Encrypting File System,加密文件系统)大文件的位置，偏移。

通过EFS逻辑文件的读写句柄，读取数据。

3)文件删除：

用户侧基于NFS共享目录进行文件删除。

查询KV小文件表记录，获取对应EFS内部的逻辑聚合文件名。

更新KV小文件表，删除小文件元数据记录。

同时根据KV记录的逻辑大文件名，获取逻辑大文件依然存在的聚合小文件数量，当聚合小文件全部删除后，进行聚合大文件的删除释放空间。

关于第一核心部分：元数据与目录管理中的目录管理的具体内容如下：

文件云存储对外暴露目录管理能力，支持用户按目录管理维护上传文件，目录结构的使用和展示同标准文件系统。

本申请的云存储系统内部基于目录服务目录实现目录的管理能力，通过目录服务模块的接口封装，支持目录和文件的创建，目录的遍历、删除等功能，目录的信息管理存储在数据库。为支持目录管理的高可靠性，本申请的分布式存储系统对目录服务集群进行了容灾实现，支持目录服务器的双机热备。

本申请的分布式存储系统对外可以提供多种卷共享方式，支持共享根目录（root）、bucket（根目录下的二级目录）。bucket目录下支持再创建bucket子目录，且各级目录均支持创建文件，目录管理的逻辑结构具体请参阅图2，图2是本申请提供的目录管理结构一实施例的示意图。

关于第二核心部分：数据写入流程。

本申请的分布式存储系统写入流程，客户端应用程序像使用本地文件一样，支持调用写入标准write函数进行数据写入，根据写入位置的不同，可以将写入流程区分为：追加写和修改写两个阶段。

其中，追加写流程相对修改对文件云存储来说难度相对低，仅涉及文件创建、申请空间、数据写入等基础流程，并未涉及原有数据的修改与覆盖，数据不一致场景少，追加写关键流程举例如上述图1系统架构图。客户端应用程序，最终调用云存储SDK与管理节点进行信令流交互申请创建文件与申请空间；请求到可以写入的存储节点后，进行数据流的写入即可。

关于修改写流程，本申请支持对分布式文件云存储中文件进行任意位置的修改写操作，像本地文件系统对文件的修改操作一样。分布式对象存储内部通过分布式纠删码条带缓存与两阶段提交模型的设计，并且针对两阶段修改模型的异常进行处理，显著降低修改写的数据不一致窗口，提升数据修改写的可靠性。

具体请参阅图3和图4，图3是本申请提供的数据修改写方法一实施例的流程示意图，图4是本申请提供的两阶段修改写的流程示意图。

如图3所示，其具体步骤如下：

步骤S11：响应于文件修改写指令，客户端服务通过元数据节点打开对象文件。

在本申请实施例中，SDK，即客户端服务通过MDS打开文件获取对象文件。然后，用户通过文件修改写指令输入对象文件中需要修改写的偏移位置，SDK通过seek定位到对象文件中的相应位置。

具体地，用户决定对文件进行修改写操作，通过SDK传入文件名、打开文件模式为读写模式以完成文件open动作。其中，本申请提供的读写模式能够同时支持对文件的读、修改写、追加写等功能。

SDK收到文件名后，去元数据节点MDS打开对象文件object，并获取与之相应的object元数据信息，包含该object对应block数据块的DN（数据节点）分布列表。对应地，打开模式使用用户传入的读写模式，并由MDS返回给SDK该对象文件的元数据信息。

步骤S12：客户端服务基于文件修改写指令指定的偏移和修改长度，定位到对象文件的逻辑偏移位置。

步骤S13：客户端服务将修改写数据写入多个数据分片中，并将数据分片发送到对应的数据节点。

在本申请实施例中，SDK模块先将修改写数据在内部条带缓存中修改，条带缓存数据修改完成后，内部进行异步条带缓存数据刷盘操作。写入磁盘前会根据指定EC规则，计算出校验块数据，通过网络协议发起预修改请求到对应数据节点DataNode服务。

具体地，SDK将修改数据修改写此偏移后的缓存区域，缓存逻辑上由多个strip组成，strip由N+M个piece组成，用户数据存放在piece中，每个piece的数据结构包含一个用户数据分片。

SDK每次写入缓存后，触发一次刷缓存动作，目标是将strip中的多个piece按照冗余规则，分发到多个DN数据节点上，落到物理磁盘上。从SDK缓存中取出满条带strip，此时根据文件的元数据和strip内部piece数据结构中的文件详细信息，可以获取到每个piece对应的目标数据节点IP信息。

进一步地，SDK根据总的数据块的piece的数量，分别到DN节点请求打开真实block文件，以N+M=3+1，偏移在文件有效长度内为例，总的数据分片为4片，所以到4个数据节点DN上打开block1、block2、block3、block4。

Block打开后，SDK将每个piece的数据通过网络发送到对应的DN节点，DN收到数据后，先将数据保存到缓存，缓存中的数据为修改后的目标数据，响应SDK成功结果。如图4所述，DN1中的BLK（Block）1写入数据；DN2中的BLK2写入数据；DN3中的BLK3写入数据。

步骤S14：数据节点将数据分片进行缓存，并返回预修改结果。

在本申请实施例中，数据节点DataNode服务在接收到预修改的数据请求后，不会立即修改真实磁盘上面的block数据，而是先在内存对block数据进行缓存，并返回SDK模块此次预修改结果。

步骤S15：在预修改结果满足预设条件时，客户端服务向数据节点发送二阶段提交请求。

在本申请实施例中，SDK模块根据纠删码所有数据分片的预修改结果综合判断，是否进行二阶段的commit提交操作；当预修改成功数量大于等于EC的容错能力时，进行二阶段的commit提交刷盘，否则SDK通知DataNode服务放弃缓存的预修改内容，进行预修改操作的回退。

具体地，SDK收到数据第一阶段写入成功后结果，统计数量。以上述的N+M=3+1为例，至少3个成功后，满足EC规则，SDK可以进行第二个提交请求。

SDK发送第二阶段数据提交请求，DN在收到提交请求后，将缓存中的数据覆盖写入原block对应偏移位置，实现数据修改写，并响应SDK，更新最新的文件真实长度。

步骤S16：数据节点根据二阶段提交请求将缓存的数据分片写入对象文件。

在本申请实施例中，在图4所示的两阶段修改写过程中，SDK模块充当协调者角色，整个系统通过将待修改数据进行多次缓存（条带缓存、DN内部缓存），避免和减少进行原地修改原始数据发生错误无法回滚导致的数据不一致问题；能显著提升系统的可靠性和数据一致性。

进一步地，针对图4所示的两阶段修改写过程，本申请还提供了过程中各阶段的异常处理逻辑，具体请参阅图5，图5是本申请提供的两阶段修改过程的异常处理的逻辑示意图。

如图5所示，在两阶段提交过程中，各阶段实际可能发生的异常归纳起来有如下4种场景：

1)预修改写前故障（Modify OBJ(Offset,data)，writeid）：预修改前系统发生部分节点故障，或者故障超过容错范围；都对修改写动作本身无影响。故障节点数量满足容错要求则继续进行修改写流程；不满足容错要求则停止修改写流程，此场景本身不会发生数据不一致，无需特殊处理。

2)预修改写中故障（case1、case2、case3）：写1-n个block过程中，故障部分节点。当故障超出容错范围，则不进行二阶段提交，由SDK通知DN发起回退请求；当故障在容错范围内，则正常的数据块block继续由SDK向DN发起二阶段提交，部分故障节点对于的block数据块，由SDK向MDS服务汇报异常坏块更新文件最新状态，即二阶段提交完成后进行上报。通过对异常场景的兼容和故障的上报处理，实现对修改写中故障的兼容。

3)提交过程中故障（Commit，writeid）：部分节点提交成功，部分节点提交失败的场景。因此时预修改以完成，最新修改数据存储节点已缓存。此时本节点内数据二阶段提交写盘，SDK会统筹二阶段提交各个存储节点返回的提交结果，并且结合DN对于提交数据块的CRC（循环冗余校验码，Cyclic Redundancy Check）校验机制等综合保障提交的数据块正确性；SDK对提交失败的block上报给MDS服务数据块异常，先行标记文件状态，最终根据文件状态判断，如果文件为可恢复状态，则进行自动的文件智能恢复，提升文件容错能力。

4)提交成功后的故障（Commit sucess）：此场景表示两阶段修改写本身已经完成，属于已经持久化的数据随着硬盘硬件老化，必然存在此场景的可能性；对于此场景，云存储内部对数据块的周期性CRC校验能正确感知数据状态，异常时DN会正确上报给MDS，触发文件状态的更新和智能的数据恢复调度。

关于第三核心部分：数据读取流程。

为保证数据读取的语义正确，用户写入成功的数据应能正确读取，不应该读到历史脏数据，本系统元数据管理服务对数据写入流程进行了读写句柄缓存共享设计。因为数据读取均是从存储节点的存储介质上面直接读取，各级缓存的存在存储介质上面的数据可能是历史数据，因此，本申请的分布式存储系统对读取成功的数据按照文件id和offset进行多级缓存命中判断，命中再进行缓存数据的合并后返回客户端，以保证用户读取的是最新最全的数据内容。

具体请参阅图6和图7，图6是本申请提供的数据修改写方法另一实施例的流程示意图，图7是本申请提供的数据读取流程的示意图。

步骤S21：响应于数据读取请求，客户端服务创建文件读句柄。

在本申请实施例中，SDK模块根据数据读取请求，创建文件读句柄，初始化数据读取缓冲区。

步骤S22：客户端服务判断是否存在文件写句柄。

步骤S23：客户端服务将文件读句柄指向文件写句柄的数据缓冲区，将数据缓冲区的最新数据与已读磁盘数据合并，返回最新的读取数据。

在本申请实施例中，SDK模块在判断存在文件写句柄时，将文件读句柄指向文件写句柄缓冲区。

具体地，在边写边读场景，最新写入数据可能存在于写句柄的写缓冲区还未下刷到存储节点的存储硬盘上，此时读句柄读取无法读取最新数据，因此在读打开是如果存在写句柄，读场景需要感知写场景的存在，并在返回数据时根据缓冲区命中判断，对最终返回数据进行合并，确保最后返回数据的正确性。

然后，SDK模块通过请求文件元数据到对应存储节点读取数据分片。SDK模块需要判断存储节点已读取数据分片是否缓存命中，若是，则将存储节点缓存最新数据与已读取磁盘数据合并，然后存储节点返回数据分片到SDK模块；若否，则存储节点直接返回数据分片到SDK模块。

具体地，上述实施例的设计为降低修改写过程数据一致性风险，对修改写操作进行两阶段操作，先返回预修改数据给到存储节点，SDK根据预修改结果，通知存储节点二阶段提交。因都是异步操作，可能存在二阶段commit返回成功后，数据还在存储节点缓存，因此读取数据必须要包含这部分在缓存中的最新数据，根据是否命中的结果，返回存储节点内部合并后的最新数据给到SDK。

进一步地，图7所示的数据读取流程的整个读取过程存储节点之间互相隔离，SDK充当协调者，存在某些场景，因为DN离线过等原因，存在SDK拿到的数据分片不是同一时间写入的数据，如下场景的数据脏读问题，理应进行数据恢复。本申请按通过事务id的设计，初始值0，每次写入和修改都加1，通过事务id的判断能正确识别分片数据的一致性，保证数据读取的正确性，具体请参阅图8，图8是本申请提供的数据节点返回数据一实施例的示意图。

关于第四核心部分：NFS卷共享。

本申请所涉及的文件云存储系统，是指在分布式云存储底座之上实现标准的文件存储能力，提供可扩展的共享文件存储服务。文件云存储兼容Posix接口，可以支持跨平台访问，能保证数据一致性，对外用户可通过标准NFS协议访问文件存储系统。本申请涉及文件云存储系统，底层通过动态纠删码技术实现数据的可靠性保证；文件云存储系统的存储容量支持弹性扩展，用户无感知不影响用户业务，同时文件存储的性能随着存储容量的增长而线性增长，对外提供高可靠、高性能的服务。

本申请所涉及的Fuse用户态文件系统，是一个用户态的文件系统框架。具体如图9所示，图9是本申请提供的用户态文件系统的工作流程示意图。本申请的Fuse用户态文件系统由内核模块（Fuse.ko）、用户态（libFuse.*）和挂载工具Fusemount等组成。文件系统通常工作在内核态，而Fuse则允许文件系统在用户态实现，使得文件系统实现更加灵活。

如图9所示，Fuse用户态文件系统的IO流程为：用户的IO请求（Is-I/tmp/file_on_fuse_fs）经过VFS（虚拟文件系统）传递给内核Fuse模块；Fuse内核模块将请求转发给mount工具对应的用户态程序（./fuse_user）进行处理，处理之后的结果按原路返回。

本申请的数据修改写方法能更好的保证分布式文件系统中修改写场景的数据一致性；通过二阶段提交模型，减小提交阶段各种异常导致的数据不一致窗口期，达到提高数据一致性的目的。

本申请的数据修改写方法修改写成本低，直接使用SDK作为协调者，通过独特的SDK缓存设计，同时满足读、写、修改写对缓存的需求，在SDK中前置完成数据的修改写，相较去直接去各节点修改目标数据开销更低，效率更高。

本申请提供标准的Posix能力：常见的分布式文件存储系统如HDFS，无法支持标准的Posix接口（如不支持truncate操作），用户需要感知其特殊语法，但是基于此专利的文件云存储系统，通过基于Fuse的标准Posix的实现，能够兼容90%以上的标准文件语义。

本申请支持NFS等协议共享：使用简单，使用者不必关注内部流程，对外像本地文件系统一样简单；通过NFS协议共享支持windows和Linux多种形式的挂载。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

为实现上述数据修改写方法，本申请还提出了一种数据修改写装置，具体请参阅图10，图10是本申请提供的数据修改写装置一实施例的结构示意图。

本实施例的数据修改写装置400包括处理器41、存储器42、输入输出设备43以及总线44。

该处理器41、存储器42、输入输出设备43分别与总线44相连，该存储器42中存储有程序数据，处理器41用于执行程序数据以实现上述实施例所述的数据修改写方法。

在本申请实施例中，处理器41还可以称为CPU（Central Processing Unit，中央处理单元）。处理器41可能是一种集成电路芯片，具有信号的处理能力。处理器41还可以是通用处理器、数字信号处理器（DSP，Digital Signal Process）、专用集成电路（ASIC，Application Specific Integrated Circuit）、现场可编程门阵列（FPGA，FieldProgrammable Gate Array）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器41也可以是任何常规的处理器等。

本申请还提供一种计算机存储介质，请继续参阅图11，图11是本申请提供的计算机存储介质一实施例的结构示意图，该计算机存储介质600中存储有计算机程序61，该计算机程序61在被处理器执行时，用以实现上述实施例的数据修改写方法。

本申请的实施例以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (12)

1.一种数据修改写方法，其特征在于，所述数据修改写方法应用于一种分布式存储系统，其中，所述分布式存储系统包括客户端服务、元数据节点以及数据节点，所述数据修改写方法包括：

响应于文件修改写指令，所述客户端服务通过所述元数据节点打开对象文件；

所述客户端服务基于所述文件修改写指令指定的偏移和修改长度，定位到所述对象文件的逻辑偏移位置；

所述客户端服务将修改写数据写入多个数据分片中，并将所述数据分片发送到对应的数据节点

所述数据节点将所述数据分片进行缓存，并返回预修改结果；

在所述预修改结果满足预设条件时，所述客户端服务向所述数据节点发送二阶段提交请求；

所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件。

2.根据权利要求1所述的数据修改写方法，其特征在于，

所述客户端服务将修改写数据写入多个数据分片中，包括：

所述客户端服务将所述修改写数据在内部条带缓存进行修改，获取条带缓存数据；

所述客户端服务根据所述条带缓存数据，计算校验块数据；

所述客户端服务将所述修改写数据以及所述校验块数据写入所述多个数据分片中。

3.根据权利要求1或2所述的数据修改写方法，其特征在于，

所述数据节点将所述数据分片进行缓存，并返回预修改结果之后，所述数据修改写方法还包括：

在所述预修改结果不满足预设条件时，所述客户端服务向所述数据节点发送回退请求；

在所述预修改结果满足预设条件时，所述客户端服务向返回预修改成功结果的数据节点发送二阶段提交请求。

4.根据权利要求1所述的数据修改写方法，其特征在于，

所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件之后，所述数据修改写方法还包括：

所述客户端服务获取所述数据节点的二阶段修改结果，并将所述二阶段修改结果为失败的数据块上报到所述元数据节点；

所述元数据节点判断所述数据块为可恢复状态时，则进行文件智能恢复。

5.根据权利要求1或4所述的数据修改写方法，其特征在于，

所述数据节点根据所述二阶段提交请求将所述缓存的数据分片写入所述对象文件之后，所述数据修改写方法还包括：

所述数据节点对存储的数据块进行周期性循环冗余校验，获取数据块状态；

在所述数据块状态为异常时，所述数据节点将对应的数据块信息上报到所述元数据节点，以使所述元数据节点进行文件状态更新或文件数据恢复。

6.根据权利要求1所述的数据修改写方法，其特征在于，

所述数据修改写方法，还包括：

响应于数据读取请求，所述客户端服务创建文件读句柄；

所述客户端服务判断是否存在文件写句柄；

若是，所述客户端服务将所述文件读句柄指向所述文件写句柄的数据缓冲区，将所述数据缓冲区的最新数据与已读磁盘数据合并，返回最新的读取数据。

7.根据权利要求6所述的数据修改写方法，其特征在于，

所述客户端服务将所述文件读句柄指向所述文件写句柄的数据缓冲区之后，所述数据修改写方法包括：

所述客户端服务获取各数据节点的数据缓冲区的最新分片数据及其事务标识号；

所述客户端服务判断所述各数据节点的事务标识号是否一致；

若是，所述客户端服务将所述个数据节点的最新分片数据进行合并，得到所述数据缓冲区的最新数据。

8.根据权利要求1所述的数据修改写方法，其特征在于，

用户通过用户态文件系统访问所述分布式存储系统，其中，所述用户态文件系统包括内核模块、用户态以及挂载工具。

9.根据权利要求1所述的数据修改写方法，其特征在于，

所述分布式存储系统通过键值对存储模块维护目录管理结构，其中，所述目录管理结构包括根目录以及用户目录，所述用户目录为分桶表。

10.根据权利要求9所述的数据修改写方法，其特征在于，

所述分桶表内存储有大文件表和/或小文件表，其中，所述大文件表存储逻辑大文件属性信息，所述小文件表存储逻辑小文件属性信息，以及小文件与大文件的映射关系；其中，同一分桶表的小文件写入同一逻辑大文件。

11.一种数据修改写装置，其特征在于，所述数据修改写装置包括存储器以及与所述存储器耦接的处理器；

其中，所述存储器用于存储程序数据，所述处理器用于执行所述程序数据以实现如权利要求1至10任一项所述的数据修改写方法。

12.一种计算机存储介质，其特征在于，所述计算机存储介质用于存储程序数据，所述程序数据在被计算机执行时，用以实现如权利要求1至10任一项所述的数据修改写方法。