CN107491264A - 一种分布式系统中的数据写入方法及装置 - Google Patents

Abstract

一种分布式系统中的数据写入方法及装置；所述数据写入方法，包括：当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；检测到依次发起的写数据请求中任一次写数据请求成功后停止发起写数据请求。本申请能降低写入延时毛刺率，并且能自适应调整冗余写数据请求的发送间隔。

Description

一种分布式系统中的数据写入方法及装置

技术领域

本发明涉及分布式存储领域，尤其涉及一种分布式系统中的数据写入方法及装置。

背景技术

云计算技术现在正逐渐普及，分布式存储是云计算要解决的最基本的问题之一。分布式存储系统将数据存储在物理上分散的多个存储节点上，对这些节点的资源进行统一管理与分配，并向用户提供文件访问接口，解决了本地存储系统在文件大小、文件数量、打开文件数等的限制问题。

现在典型的分布式存储系统都采用了三端模式来部署，通常包括主控服务器、存储节点及客户端。主控服务器也称为元数据服务器、名字服务器、命名空间管理模块及管理服务器等，实际部署时可以采用冗余的工作方式。存储节点也称为数据存储服务器、数据服务器、存储服务器、块服务器、数据管理模块等。客户端也称为客户机，可以是各种应用服务器，也可以是终端用户。常用的分布式存储系统包括谷歌文件系统(Google File System，GFS)、淘宝文件系统(Taobao FileSystem，TFS)、MooseFS文件系统等。

以谷歌文件系统为例，如图1所示，客户端(Client)用于为分布式存储系统的用户提供各种接口；块服务器(Chunkserver)用于具体管理用户文件，用户文件的数据以多副本的方式保存在不同的块服务器中；主控服务器(Master)用于管理元数据(meta data)。客户端发送文件名称和块索引到主控服务器，主控服务器返回块句柄和块位置；客户端发送块句柄和字节范围到块服务器，块服务器返回块数据。块服务器还向主控服务器上报块服务器状态，主控服务器下发对于块服务器的指令给块服务器。

谷歌文件系统中，用户文件的所有元数据存储在主控服务器中，包括文件的名字空间和Chunk(块)名字空间、从文件到块的映射以及块对应的数据服务器等等。为了提高访问元数据的吞吐量，所有的元数据都缓存在主控服务器的内存中。主控服务器占用内存的大小与文件数量成正比，主控服务器所在机器的物理内存大小决定了集群所能存储的文件数量。

文件被分成固定大小的块。每个文件在主控服务器只有一个可写块。块服务器将块当作Linux文件存储在本地磁盘。出于可靠性考虑，每一个块被复制到多个块服务器上，用于存储某一文件的可写块的副本的块服务器可称为该文件对应的块服务器。默认情况下，在块服务器上保存3个副本，每个副本存储在一个块服务器上。客户端需要向文件写数据时，可以询问主控服务器该文件对应的块服务器。客户端在一段时间内将这些信息缓存，在后续的操作中直接和块服务器交互。

下面以谷歌文件系统为例，对现有分布式存储系统典型的写流程进行描述。客户端接收到用户对某一文件(以下称为第一文件)写数据的请求后，执行以下处理：

步骤一，客户端向主控服务器请求第一文件的可写块的信息；

步骤二，主控服务器将第一文件的一个可写块的信息及其对应的多个块服务器的信息返回给客户端；

可写块的信息可以是该可写块的标识信息，如块句柄(Chunk-handle)等，块服务器的信息可以是块服务器的地址，也可是其他可用于获取地址的信息如名称、标识等。

客户端对第一文件进行的一次写操作的过程如下：

步骤三，客户端向所述多个块服务器发起对所述第一文件的写数据请求，并等待所述多个块服务器返回写数据的结果；

步骤四，如果所述多个数据服务器都向客户端返回写数据成功，客户端即判定对第一文件的此次写操作成功，向用户返回写数据成功。

本发明的发明人经研究发现，现有方案存在以下缺陷：

一次分布式写操作的延时取决于最慢的一个副本的写延时。对于关注延时的在线系统来说，3个副本总的延时分布比单副本要差很多。例如：单副本写延时小于20毫秒的比例是0.9；那么3个副本写延时小于20毫秒的比例是0.9³＝0.729。由于需要3个副本中任何一个都要小于20毫秒，3个副本写延时才会小于20毫秒，因此从写延时的毛刺率来说，3个副本中只要有一个写操作出现毛刺，这次分布式写操作的延时就是一个毛刺。因此，现有分布式存储系统中存在写操作的延时毛刺率高的问题。

发明内容

本申请提供一种分布式系统中的数据写入方法及装置，能降低写入延时毛刺率，并且能自适应调整冗余写数据请求的发送间隔。

本申请采用如下技术方案。

一种分布式系统中的数据写入方法，包括：

当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

检测到依次发起的写数据请求中任一次写数据请求成功后停止发起写数据请求。

可选地，所述写操作的性能指标包括：

写操作的延时，和/或，发起冗余写数据请求的次数；

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。

可选地，所述写操作的延时是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

可选地，所述的数据写入方法还包括：

在每次写操作后，记录本次写操作的延时和发起冗余写数据请求的次数。

可选地，所述第一时间间隔根据写操作的性能指标动态确定包括：

所述第一时间间隔根据L_avg以及Qps计算得到；其中，所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率Qps。

可选地，所述第一时间间隔根据L_avg以及Qps计算得到包括：

所述第一时间间隔等于预定函数的函数值；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

可选地，所述第一时间间隔根据写操作的性能指标动态确定包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。

一种分布式系统中的数据写入装置，包括：

发起模块，用于当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

检测模块，用于检测到依次发起的写操作中任一次写数据请求成功后指示所述发起模块停止发起写数据请求。

可选地，所述写操作的性能指标包括：

写操作的延时，和/或，发起冗余写数据请求的次数；

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，所述发起模块依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。

可选地，所述写操作的延时是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

可选地，所述的数据写入装置还包括：

记录模块，用于在每次写操作后，记录本次写操作的延时和发起冗余写数据请求的次数。

可选地，所述第一时间间隔根据写操作的性能指标动态确定包括：

所述第一时间间隔根据L_avg以及Qps计算得到；所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率。

可选地，所述第一时间间隔根据L_avg以及Qps计算得到包括：

将预定函数的函数值作为所述第一时间间隔；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

可选地，所述第一时间间隔根据写操作的性能指标动态确定包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。

本申请包括以下优点：

本申请至少一个备选方案允许单个文件同时有多个可写块，对多个可写块依次发起写数据请求，只要对任一个可写块发起的写数据请求成功即判定对所述文件的写操作成功，可以有效减少单文件写操作的毛刺率；依次发起写数据请求时，相邻两次发起写数据请求的时间间隔不是固定的，而是根据情况动态调整的，可以根据写操作执行过程中实时的性能指标变化而相应变化，从而能够更好地适应当前的实际情况。

本申请又一个备选方案中，所述写操作的性能指标包括写操作的延时，和/或，冗余写数据请求的次数；这样可以较为准确地反映出前端压力的变化情况；根据写操作的延时，和/或冗余写数据请求的次数来调整相邻两次发起写数据请求的时间间隔，可以使所述时间间隔能较为精确地跟随前端压力的改变而变化。

本申请又一个备选方案采用最近一段时间内的写操作延时和冗余写数据请求的频率作为确定相邻两次发起写数据请求的时间间隔的依据，可以反映出变化趋势，使调整结果更为准确。

本申请又一个备选方案中，相邻两次发起写数据请求的时间间隔随写操作延时的平均值和冗余写数据请求的频率单调递增，在压力变小的时候可以尽可能地发挥冗余写数据请求对毛刺率的优化效果，在压力变大的时候可以抑制冗余写数据请求对系统稳定性的负面影响；从而在不同压力下兼顾性能和稳定性。

当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有优点。

附图说明

图1是分布式存储系统的网络架构示意图；

图2是本发明实施例一的数据写入方法的流程图；

图3是本发明实施例二的数据写入装置的示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在一个典型的配置中，客户端或服务器可包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存(memory)。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。内存可能包括一个或多个模块。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)，快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

实施例一、一种分布式系统中的数据写入方法，如图2所示，包括步骤S110～S120：

S110、当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

S120、检测到依次发起的写数据请求中任一次写数据请求成功后停止发起写数据请求。

本实施例中，所述第一时间间隔相当于针对用户对于第一文件的一次写请求，依次发起写数据请求时，两次相邻写数据请求之间的时间间隔，也可以看成冗余写数据请求的发送间隔；越短对毛刺率的优化效果越好，但需要的额外的资源越多。

本实施例中，动态调整意味着第一时间间隔会跟随写操作的性能指标变化而发生变化；在前端压力基本不变的场景下，写操作的性能指标基本是不变的，相当于将所述第一时间间隔设置为固定值；在压力变化明显的场景下，写操作的性能指标也会随之改变，因此第一时间间隔将也随之发生变化，比如可以在压力小的时候将第一时间间隔变小，即：针对用户对于第一文件的一次写请求，用更高的频率或者说积极发起写数据请求；在压力大的时候将第一时间间隔变大，即：针对用户对于第一文件的一次写请求，用更低的频率或者说消极发起写数据请求，从而能够更好地适应当前的实际情况。本实施例中，所述步骤S110、步骤S120可以但不限于均由客户端或设置于客户端中的装置/模块实施。所述第一时间间隔的动态确定可以但不限于由客户端完成，此时客户端可用于记录和统计写操作的性能指标，以及根据写操作的性能指标确定所述第一时间间隔；也不排除采用另外的设备完成第一时间间隔的确定并通知给客户端的做法。

本实施例中，依次发起的多次写数据请求是并发的，即一个写数据请求未收到结果时即可开始下一个写数据请求，即多个依次发起的写数据请求对应的写数据过程可以同时在进行。客户端可以对所述第一文件的多个可写块按照轮询的方式依次发起写数据请求，避免某个可写块成为写入的热点。比如先对可写块进行排序，得到每个可写块的序号；将下一次发起写数据请求针对的可写块的序号I设置为排序在第一个的可写块的序号；每当用户发起写请求的时候，根据序号I选择相应的可写块，同时将I设置为下一个可写块的序号。

本实施例中，对一个可写块发起写数据请求可以是指对该可写块对应的多个存储节点发送数据写入请求；检测到对一个可写块发起的写数据请求成功可以是指该可写块对应的多个存储节点都返回表示写成功的结果。

本实施例中，当针对用户对于第一文件的一次写请求，对第一文件的可写块发起写数据请求(无论是第几次发起写数据请求)后，如果在还未到达第一时间间隔时就检测到了对第一文件的可写块的写数据请求成功，则判定对所述第一文件的此次写操作成功，不再继续对剩余的其它可写块发起写数据请求，此时可以向用户返回表示写成功的消息。所述检测到对第一文件的可写块的写数据请求成功可以是检测到依次发起的写数据请求中任一次写数据请求成功。比如一个示例中，假设第一文件有可写块A、B、C、D；收到用户对于第一文件的写请求后，依次对可写块A、B、C发起写数据请求；当对可写块C发起写数据请求后未到达所述第一时间间隔时，如果检测到写数据请求成功(无论是对可写块A、B、C发起的写数据请求中的哪一次成功)，都不再对可写块D发起写数据请求。

本实施例中，如果一直未检测到写数据请求成功，则会向所述多个可写块中的其余可写块(即未发送过写数据请求的可写块)继续依次发起写数据请求，或者对所述多个可写块中的S个可写块中的其余可写块发起写数据请求后停止继续发起写数据请求；S为整数，表示配置的可写块最大并发数，2≤S≤M，M也为整数，表示所述第一文件的可写块的数量。比如上面的示例中，M为4；从对可写块C发起写数据请求开始计时，如果到达所述第一时间间隔时还未检测到之前发起的写数据请求中任一次写数据请求成功，则有两种可能：假设没有设置S或者S等于M，则继续对可写块D发起写数据请求；假设S为3，则不再对可写块D发起写数据请求。类似地，假如S为2，则对可写块A、B依次发起写数据请求后，无论是否检测到写数据请求成功，都不再对其它可写块发起写数据请求。

其中，初始的第一时间间隔以及S可以由用户进行配置，比如对客户端与用户之间的接口协议进行扩展，初始的第一时间间隔T和可写块最大并发数S可以通过客户端与用户之间的接口来配置，即客户端根据用户的配置指令配置。M可以由用户通过客户端与用户之间的接口进行配置，或者由主控服务器配置，供用户通过客户端与用户之间的接口获取。

本文中，在对第一文件的写操作中用到的配置参数如M、S等，均是适用于第一文件的配置参数。可以是针对第一文件而配置，相应配置指令中会指定第一文件或者包括第一文件的文件集合，而该配置参数将作为第一文件的属性信息保存；也可以针对所有文件统一配置，此时相应的配置指令无需指定文件。

本实施例的一种备选方案中，可以由客户端在收到用户对第一文件的写请求之后，或客户端启动后(客户端固定对应于第一文件的情况)，通过向主控服务器发送对第一文件可写块信息的查询请求(也即获取第一文件可写块信息的请求)，从主控服务器获取所述第一文件的多个可写块的信息，及所述多个可写块中每一可写块对应的多个存储节点的信息。该查询请求也可以通过定时或其它方式触发。客户端获取到文件的可写块信息后缓存在本地，如果宕机重启可以从主控服务器重新获取。

在本备选方案的一个示例中，假定为第一文件配置的文件可写块数M为3，客户端从主控服务器获取到第一文件三个可写块的块句柄，每个可写块的块句柄对应三个数据服务器的地址，其中的每个数据服务器用于保存该可写块的一个副本。

该备选方案可以通过对客户端用于向主控服务器获取文件可写块信息的协议进行扩展实现，增加对一个文件有多个可写块的支持。M可以由用户配置后，供主控服务器通过客户端与主控服务器之间的接口获取，或者由主控服务器通过客户端与主控服务器之间的接口配置。

本备选方案中，所述主控服务器可以负责存储元数据，包括每个文件当前正在写的块的信息、每个文件当前所允许的可写块的数量等；以上元数据在Master端都需要持久化的保存，宕机重启后不能丢失。

所述主控服务器还可以记录当前可写块所在的所有存储节点(这部分信息以缓存的形式存在，不需要持久化，宕机重启后可以根据上面记录的元数据恢复出来)；在分配存储节点时，最好尽量避免新分配的存储节点与记录的存储节点重复，但如果集群可写的存储节点数量太少，无法满足不重复的要求的时候，也允许重复。

本实施例的一种备选方案中，所述方法还可以包括：

客户端根据用户指令，向所述主控服务器发送对所述第一文件或多个文件的文件可写块的数量的查询请求；

所述客户端接收所述主控服务器返回的查询结果。

本备选方案中，对客户端和用户之间的接口进行扩展，以及客户端与主控服务器之间的接口进行扩展，使其支持用户通过客户端对文件可写块数量进行查询。

本实施例的一种备选方案中，所述方法还可以包括：

所述客户端根据用户指令，向所述主控服务器发送对所述第一文件或多个文件的文件可写块数量的配置请求，携带用户为所述第一文件或多个文件配置的文件可写块数量；

所述客户端接收所述主控服务器返回的配置结果。

本备选方案中，对客户端和用户之间的接口进行扩展，以及客户端与主控服务器之间的接口进行扩展，使其支持用户通过客户端对文件可写块数量进行配置。

本实施例的一种备选方案中，所述写操作的性能指标可以包括：

写操作的延时，和/或，发起冗余写数据请求的次数。

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。比如假设第一文件有三个可写块A、B、C；收到用户对于第一文件的写请求后，先对可写块A发起写数据请求(即：第一次发起的写数据请求)，等待所述第一时间间隔后，对可写块B发起写数据请求(即：冗余写数据请求)；之后对可写块C发起的写数据请求也是冗余写数据请求。假如第一次发起写数据请求后，在所述第一时间间隔内就检测到写数据请求成功，则针对用户本次的写请求，冗余写数据请求的次数为0。

其中，一次所述写操作的延时是针对一次用户写请求而言的延时，可以定义为接收到用户写请求后第一次发起写数据请求的时刻，与检测到任一次写数据请求成功的时刻之间所间隔的时间长度；如果对第一文件的可写块发起的写数据请求都没有成功，则写操作的延时也可以为预定的超时时间长度(即，从第一次发起写数据请求开始，到达该超时时间长度时仍未检测到写数据请求成功，则判断写操作失败)；一次所述写操作的延时也可以定义为从接收到用户写请求开始，到完成该写请求(无论写操作成功或写操作失败)为止整个过程的耗时。

本备选方案中，如果对于依次发起的多次写数据请求中的两次或两次以上都检测到成功，则以第一次检测到成功的时刻为准计算所述写操作的延时。比如对可写块A、B依次发起写数据请求后，先检测到对可写块B发起的写数据请求成功，后来又检测到对可写块A发起的写数据请求成功，则可以将对可写块A发起写数据请求的时刻、和检测到对可写块B发起的写数据请求成功的时刻之间相隔的时间长度作为所述写操作的延时。对于写操作的延时的定义不限于上面的示例，还可以根据需要自行设置。

本备选方案中，所述写操作的延时、发起冗余写数据请求的次数可以较为准确地反映出前端压力的变化情况；根据写操作的延时，和/或，冗余写数据请求的次数来确定第一时间间隔，可以使第一时间间隔能较为精确地跟随前端压力的改变而变化。

本备选方案中，所述写操作的延时可以是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数可以是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

本备选方案中，所述方法还可以包括：

在每次写操作后，记录下对于用户的本次写请求，写操作的延时和发起冗余写数据请求的次数。

本备选方案的一种实施方式中，可以只根据写操作的延时、或者只根据发起冗余写数据请求的次数来确定所述第一时间间隔；可以设置成该第一时间间隔随写操作的延时或发起冗余写数据请求的次数变大而变大。本实施方式可以只记录一种性能指标，节省存储资源，而且确定所述第一时间间隔时的处理也会相对简单，可以少占用处理资源，提高处理效率。

本实施方式一种可选的方案是根据以写操作的延时或发起冗余写数据请求的次数作为自变量，以第一时间间隔作为应变量的函数，来确定所述第一时间间隔。另一种可选的方案是建立写操作的延时或发起冗余写数据请求的数值范围和第一时间间隔之间的对应关系，根据该对应关系来确定第一时间间隔；比如当写操作的延时或发起冗余写数据请求的次数属于第一数值范围时，所述第一时间间隔为第一时间长度T1，当写操作的延时或发起冗余写数据请求的次数属于第二数值范围时，所述第一时间间隔为第二时间长度T2，以此类推。当然，也可以使用其它根据写操作的延时或发起冗余写数据请求的次数来确定所述第一时间间隔的方案。

本备选方案的另一种实施方式中，可以根据写操作的延时和发起冗余写数据请求的次数共同来确定所述第一时间间隔；可以设置成所述第一时间间隔随写操作的延时和发起冗余写数据请求的次数变大而变大。本实施方式两个性能指标可以互相作为参考和修正，使结果更加准确。

本实施方式一种可选的方案是根据以写操作的延时以及发起冗余写数据请求的次数作为自变量，以所述第一时间间隔作为应变量的函数，来确定所述第一时间间隔。另一种可选的方案是对写操作的延时和发起冗余写数据请求的次数这两者进行预定计算，建立计算得到的结果的数值范围和所述第一时间间隔之间的对应关系，根据该对应关系确定所述第一时间间隔。当然，也可以使用其它根据写操作的延时和发起冗余写数据请求的次数来确定所述第一时间间隔的方案。

本备选方案的一种实施方式中，利用前一次写操作的性能指标来确定所述第一时间间隔，本实施方式可以节省存储空间，计算量也相对较小，计算速度快，前端压力的变化可以立刻体现在第一时间间隔的变化上，实时性比较好。

本备选方案的另一种实施方式中，利用多次写操作(可以是待确定所述第一时间间隔的时刻之前一段时间内的多次写操作，也可以是之前多次写操作)的性能指标来确定所述第一时间间隔，本实施方式可以体现出前端压力的变化趋势，能够减缓前端压力暂时性的突变带来的影响，更为客观和准确。

其它备选方案中，也可以选用写操作的其它性能指标或性能指标的组合作为确定所述第一时间间隔的依据；或者选用写操作的其它性能指标或性能指标的组合，与写操作的延时，和/或，发起冗余写数据请求的次数进行组合，作为确定所述第一时间间隔的依据。所述其它性能指标比如但不限于包括：数据吞吐率、写操作的成功率、收到用户的写请求后发起冗余写数据请求的概率或比例等。

本实施例的一种备选方案中，所述第一时间间隔根据写操作的性能指标动态确定可以包括：

所述第一时间间隔根据L_avg以及Qps计算得到；其中，所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率Qps。

本实施方式采用最近一段时间内的写操作的延时和发起冗余写数据请求的次数作为确定第一时间间隔的依据，根据延时的平均值和单位时间中发起冗余写数据请求的次数进行计算，可以得到一段时间内延时和发起次数的变化趋势，从而可以更加准确地反映出前端压力的可以反映出变化趋势，使确定的第一时间间隔更为合适。

本实施方式中，所述预定长度可以根据经验值或试验自行确定和修改。所述待确定所述第一时间间隔的时刻可以但不限于是指为了确定所述第一时间间隔而计算L_avg以及Qps的时刻、或者触发进行第一时间间隔确定的时刻(比如周期性确定第一时间间隔的情况中到达确定周期的时刻、设置的触发确定第一时间间隔的条件被满足的时刻等)。所述Qps是用待确定所述第一时间间隔的时刻之前预定长度的时间内发起冗余写数据请求的总次数(即，这段时间内针对用户一次或多次写请求，总共发起的冗余写数据请求的次数)除以所述预定长度。比如预定长度为2秒，在最近的2秒内，发起冗余写数据请求的总次数为10，则Qps为5次/秒。

其它实施方式中，也可以采用另外的方式实现对所述第一时间间隔的动态确定，比如采用待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时及发送冗余写数据请求的次数的的累加值来计算所述第一时间间隔；再比如根据待确定所述第一时间间隔的时刻之前预定长度的时间内发送冗余写数据请求的次数以及写操作的次数，求出每次写操作平均发送的冗余写数据请求的次数，然后和延时的平均值一起用于计算所述第一时间间隔。

本实施方式中，所述第一时间间隔根据L_avg以及Qps计算得到可以包括：

所述第一时间间隔等于预定函数的函数值；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

当前端压力变小的时候，延时和冗余写数据请求的发送频率会相应降低，因此第一时间间隔也会变短，可以尽可能地发挥冗余写数据请求对毛刺率的优化效果；当前端压力变大的时候，延时和冗余写数据请求的发送频率会相应增加，因此第一时间间隔也会变长，可以抑制冗余写数据请求对系统稳定性的负面影响。将L_avg以及Qps代入预定函数，可以非常便捷地计算出相应的第一时间间隔。

本实施方式中，所述预定函数可以但不限于为：

a1×L_avg+a2×Qps+a3；

或者，b1×L_avg×Qps+b2；

其中，a1、a2、a3、b1、b2是预定值。

实际应用中，也可以对上述函数式进行变换，比如改变计算符号等；还可以采用其它不同的函数作为所述预定函数。

当然，也可以采用其它方式计算所述第一时间间隔，比如将L_avg以及Qps代入预定的第一计算式；将得到的计算结果代入第二计算式得到第一时间间隔；再比如根据L_avg以及Qps计算出第一时间间隔的调整方向(增加或减少)和步长，根据调整方向、预定步长或根据L_avg和/或Qps计算出的步长，在当前的第一时间间隔基础上得到最新的第一时间间隔。

本实施例的一种备选方案中，所述第一时间间隔根据写操作的性能指标动态确定可以包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。

本备选方案中，所述触发条件可以但不限于包括以下任一个：收到用户的写请求、发起第一次写数据请求、完成一次用户的写请求、写操作的性能指标发生改变或变动幅度超过阈值等。

本备选方案中，在周期性动态确定第一时间间隔的情况下，当收到用户写请求并发起第一次写数据请求后，根据本周期确定的第一时间间隔发起冗余写数据请求。

下面用两个例子说明本实施例。

第一个例子中，存储节点为块服务器；客户端统计整个进程在最近一段时间内写操作的延时平均值L_avg、和实际发起冗余写数据请求的频率Qps，根据第一时间间隔T的自适应函数F计算第一时间间隔T：T＝F(Lavg，Qps)，其中函数F的值随L_avg单调递增、随Qps单调递增。

数据写入流程包括如下步骤201～211：

201、客户端启动，用户进行如下两个设置：

a)设置一份用户数据同时写多个块的最大并发数S，S＜M；

b)设置向多个块依次发起写数据请求的初始的第一时间间隔T；

202、客户端向主控服务器发送获取文件F所有可以写的块的信息的请求；本例中客户端专门用于文件F的写入，在其它例子中，客户端也可以等收到用户对于某个文件的写请求后，再向主控服务器获取相应文件中可以写的块的信息；

203、主控服务器收到请求后在内存中找到文件F所有可以写的块的信息和文件F可以写的块的数量M；

204、主控服务器将足够数量的可写块信息返回客户端：

如果当前文件F已有的块数量不小于M，则将这些块信息返回给客户端；

如果当前文件F已有的块数量小于M，则重新分配足够数量的块，新分配的块数量加已有的块数量等于M；将新分配和已有的块信息返回给客户端；

205、客户端收到可写块信息后按顺序缓存，得到每个可写块的序号，将下一次可写块的序号I设置为第一个可写块的序号；

206、客户端收到用户的写请求，选取序号为I的可写块发起写数据请求，即：将数据写入请求发往这个块对应的所有块服务器，将序号I修改为下一个可写块的序号。

207、在发起写数据请求T时间之后，如果这次写数据请求还没有成功，则向序号为I的可写块(即下一个块)发起相同数据的写数据请求，将序号I修改为下一个可写块的序号。重复步骤207直至检测到任一次写数据请求成功，或者1份用户数据同时在写的块数量达到预设的S。

如果客户端启动后第一次针对收到的写请求发起写数据请求，则第一时间间隔可采用初始的第一时间间隔，或者根据上次启动时的记录进行计算；如果不是第一次发起写数据请求，客户端可以根据F(L_avg，Qps)计算第一时间间隔T。计算T的操作可以在步骤201～206的任一步骤中或任一个步骤后完成，还可以周期性完成。

重复步骤207直至检测到任一次写数据请求成功是指：当某个块的所有块服务器都返回给客户端表示写成功的结果后，后续不会再发起这个数据往新块的写数据请求，客户端返回给用户表示成功的消息。如果接收到用户新的写请求则可以从步骤206开始执行。如果数据写成功前数据已经被写到了多个块上，在客户端返回给用户表示成功的消息后，又陆续收到其它块对这份数据写数据请求的结果，不管成功还是失败，这些结果都对用户透明，不影响客户端给用户的返回结果。客户端还可以在每次写请求完成后统计写操作的延时，统计每次用户写请求触发的冗余写数据请求的次数。

另外、当客户端发现某个块已经写满的时候，返回到步骤201，重新分配获取可写块的数量。

本例中，用户对文件可写块数量的查询和配置流程如下：

第一步，用户根据写入吞吐的要求，决定将可写块的数量设置为M；

第二步，用户调用用户和客户端之间的接口，请求获取当前可写块的数量；

第三步，客户端向主控服务器发起请求，获取当前可写块的数量；

第四步，Master收到客户端请求后在内存中找到文件可写块的数量N，将N返回客户端。

第五步，客户端将当前可写块数量N返回给用户；

第六步，用户根据N和M的值进行判断，如果N等于M，则无需修改；如果N不等于M，则调用用户和客户端之间的接口，设置当前可写块的数量为M；

第七步，客户端向主控服务器发起请求，将可写块数量设置为M；

第八步，主控服务器收到请求后将可写块数量设置为M，同时将这个改动持久化。返回给客户端改动成功的响应；

第九步，客户端返给给用户表示改动成功的消息。

第二个例子用具体数值描述本实施例减小毛刺率的效果。

定义超过100毫秒的写请求是毛刺，为了简化计算，同时写块的并发数S和可写块数量M都是2，向多个块依次发起写数据请求的第一时间间隔T是50毫秒。在没有采用本实施例的数据写入方法之前，一个典型的延时分布如下：

写数据请求的延时超过50毫秒的比例为0.01；

写数据请求的延时超过100毫秒的比例为0.001；

在本例中有两个并发的写数据请求，表示为P和Q：P先发出，Q在P发出50毫秒后发出。P和Q写到了两个不同的可写块上，本例中这两个块的副本位置各不相同，所以在多数情况下，P和Q可以被看成是两个独立的事件。P和Q作为各自独立的写数据请求考虑时，延时分布都与上面典型的延时分布相同。

在采用本实施例的数据写入方法之后，同样是以超过100毫秒的作为毛刺，对于一次写请求，写操作的延时超过100毫秒需要同时满足如下两个条件：

(1)写数据请求P的延时超过100毫秒；

(2)写数据请求Q的延时超过50毫秒(因为Q是在P之后50毫秒发出的)。

所以就有了一个简单的概率计算，写操作的延时超过100毫秒的比例为：0.01*0.001＝0.00001。

也就是说采用本实施例的数据写入方法后，毛刺率的数值降低为原先的1/100。

实施例二、一种分布式系统中的数据写入装置，如图3所示，包括：

发起模块21，用于当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

检测模块22，用于检测到依次发起的写操作中任一次写数据请求成功后指示所述发起模块21停止发起写数据请求。

本实施例中，所述发起模块21是上述装置中负责向可写块请求写数据的部分，可以是软件、硬件或两者的结合。

本实施例中，所述检测模块22是上述装置中负责检测写数据是否成功的部分，可以是软件、硬件或两者的结合。

本实施例的装置可以但不限于设置于客户端中，也可以采用分布式方式设置在不同设备中。

本实施例的一种备选方案中，所述写操作的性能指标可以包括：

写操作的延时，和/或，发起冗余写数据请求的次数；

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，所述发起模块依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。

本备选方案中，所述写操作的延时可以是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数可以是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

本备选方案中，所述装置还可以包括：

记录模块，用于在每次写操作后，记录本次写操作的延时和发起冗余写数据请求的次数。

本实施例的一种备选方案中，所述第一时间间隔根据写操作的性能指标动态确定可以包括：

所述第一时间间隔根据L_avg以及Qps计算得到；所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率。

本备选方案中，所述第一时间间隔根据L_avg以及Qps计算得到可以包括：

将预定函数的函数值作为所述第一时间间隔；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

本备选方案中，所述预定函数可以但不限于为：

a1×L_avg+a2×Qps+a3；

或者，b1×L_avg×Qps+b2；

其中，a1、a2、a3、b1、b2是预定值。

实际应用中，也可以对上述函数式进行变换，比如改变计算符号等；还可以采用其它不同的函数作为所述预定函数。

本实施例的一种备选方案中，所述第一时间间隔根据写操作的性能指标动态确定可以包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。

本实施例的其它实现细节可参考实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。

Claims (14)

1.一种分布式系统中的数据写入方法，包括：

当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

检测到依次发起的写数据请求中任一次写数据请求成功后停止发起写数据请求。

2.如权利要求1所述的数据写入方法，其特征在于，所述写操作的性能指标包括：

写操作的延时，和/或，发起冗余写数据请求的次数；

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。

3.如权利要求2所述的数据写入方法，其特征在于：

所述写操作的延时是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

4.如权利要求2所述的数据写入方法，其特征在于，还包括：

在每次写操作后，记录本次写操作的延时和发起冗余写数据请求的次数。

5.如权利要求1所述的数据写入方法，其特征在于，所述第一时间间隔根据写操作的性能指标动态确定包括：

所述第一时间间隔根据L_avg以及Qps计算得到；其中，所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率Qps。

6.如权利要求5所述的数据写入方法，其特征在于，所述第一时间间隔根据L_avg以及Qps计算得到包括：

所述第一时间间隔等于预定函数的函数值；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

7.如权利要求1～6中任一项所述的数据写入方法，其特征在于，所述第一时间间隔根据写操作的性能指标动态确定包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。

8.一种分布式系统中的数据写入装置，其特征在于，包括：

发起模块，用于当收到用户对于第一文件的写请求后，按照第一时间间隔，对所述第一文件的多个可写块依次发起写数据请求；所述第一时间间隔根据写操作的性能指标动态确定，一次写操作包括针对一个写请求所发起的多次写数据请求；

检测模块，用于检测到依次发起的写操作中任一次写数据请求成功后指示所述发起模块停止发起写数据请求。

9.如权利要求8所述的数据写入装置，其特征在于，所述写操作的性能指标包括：

写操作的延时，和/或，发起冗余写数据请求的次数；

所述冗余写数据请求是指：针对用户对于第一文件的一次写请求，所述发起模块依次发起的写数据请求中，除第一次发起的写数据请求以外的写数据请求。

10.如权利要求9所述的数据写入装置，其特征在于：

所述写操作的延时是之前一次或之前多次写操作的延时，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时；

所述发起冗余写数据请求的次数是之前一次或之前多次写操作中发起冗余写数据请求的次数，或者是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作中发起冗余写数据请求的次数。

11.如权利要求9所述的数据写入装置，其特征在于，还包括：

记录模块，用于在每次写操作后，记录本次写操作的延时和发起冗余写数据请求的次数。

12.如权利要求8所述的数据写入装置，其特征在于，所述第一时间间隔根据写操作的性能指标动态确定包括：

所述第一时间间隔根据L_avg以及Qps计算得到；所述L_avg是待确定所述第一时间间隔的时刻之前预定长度的时间内，写操作的延时的平均值；所述Qps是待确定所述第一时间间隔的时刻之前预定长度的时间内，发起冗余写数据请求的频率。

13.如权利要求12所述的数据写入装置，其特征在于，所述第一时间间隔根据L_avg以及Qps计算得到包括：

将预定函数的函数值作为所述第一时间间隔；所述预定函数的自变量为L_avg、Qps，所述预定函数的函数值随L_avg单调递增，随Qps单调递增。

14.如权利要求8～13中任一项所述的数据写入装置，其特征在于，所述第一时间间隔根据写操作的性能指标动态确定包括：

周期性根据写操作的性能指标动态确定所述第一时间间隔；

或者，当满足预定的触发条件时根据写操作的性能指标动态确定所述第一时间间隔。