CN106878414A - 数据写请求处理方法、装置及分布式数据存储系统 - Google Patents

Abstract

本发明公开了一种数据写请求处理方法、装置及分布式数据存储系统。其中，方法基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，方法包括：对于一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中；从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点，能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。

Description

数据写请求处理方法、装置及分布式数据存储系统

技术领域

本发明涉及计算机网络技术领域，具体涉及一种数据写请求处理方法、装置及分布式数据存储系统。

背景技术

在分布式数据存储系统中，一般会利用分布式组件来将调用端发送的数据写请求转发给存储引擎，其中，分布式组件为反向代理服务器，具体地，可以为Nginx服务器。对于KV存储来说，Nginx内置的负载均衡的策略，无论是round-robin，还是ip_hash，还是url_hash，都不能实现根据key来进行负载均衡的需求，举例说明，以分布式组件采用的是1Primary-1Replica Shard的存储模式为例，这必然涉及到两次写存储的操作，而这两次的写入需要是两台完全不同的节点，但Nginx内置的负载均衡策略无法满足这样高度定制化的需求，其根本原因在于，Nginx的负载均衡策略将存储节点的地址等细节完全对外层屏蔽了，在编写http模块时不可能通过任何一个内置函数拿到某个存储节点的地址，也就是说这些细节对于开发者是透明的，从而限制了定制化的负载均衡策略的实现。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的数据写请求处理方法、数据写请求处理装置和相应的分布式数据存储系统。

根据本发明的一个方面，提供了一种数据写请求处理方法，该方法基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，方法包括：

对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中；

从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

根据本发明的另一方面，提供了一种数据写请求处理装置，该装置基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，装置包括：用于处理子请求的处理器；

用于处理子请求的处理器包括：

选择单元，适于对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址；

子请求处理单元，适于向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

提取单元，适于从子请求的上下文中提取出所选择的存储节点地址；

上下文写入单元，适于将提取出的存储节点地址保存至存储节点的上下文中；

连接单元，适于从存储节点的上下文中提取出存储节点地址，与存储节点建立连接；

数据写入单元，适于将数据写入到相应的存储节点。

根据本发明的另一方面，提供了一种分布式数据存储系统，包括：调用端、分布式组件和存储节点；其中，分布式组件包括上述数据写请求处理装置。

根据本发明提供的方案，对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中，从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中，从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。在本发明方案中，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的数据写请求处理方法的流程示意图；

图2示出了根据本发明另一个实施例的数据写请求处理方法的流程示意图；

图3示出了根据本发明一个实施例的数据写请求处理装置的结构示意图；

图4示出了根据本发明另一个实施例的数据写请求处理装置的结构示意图；

图5示出了根据本发明一个实施例的分布式数据存储系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明提出了一种数据写请求处理方法及装置，适用于分布式数据存储系统，该系统包括：客户端、Linux虚拟服务器集群(LVS)、分布式组件(HustDB HA，简称HA)和存储引擎(HustDB)。其中，分布式组件为反向代理服务器，具体可以是Nginx服务器。客户端和LVS可作为调用端，例如，客户端和LVS之间由于业务交互产生数据，LVS发送数据写请求，期望将业务相关数据写入存储节点中。另外，在一些特殊业务场景中，调用端可能为其它上层应用或调用程序，例如，分布式组件内部的调用程序。调用端具体与实际业务情况相关联，本发明对此不作限制。

在该分布式数据存储系统中，将分布式组件与存储引擎分离，存储引擎只负责数据存储，以及对外提供http接口，以供分布式组件根据所提供的http接口向对应的存储节点写入数据，其中，存储引擎包括多个存储节点，各个存储节点是相互独立的，存储节点彼此之间不会直接进行通信，从而降低了存储引擎的复杂度。

存储节点可以为键值(Key-Value，以下简称：KV)存储数据库，这是一种NoSQL(非关系型数据库)模型，其数据按照键值对的形式进行组织、索引和存储。KV存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。

目前在生产环境，使用较多的K-V存储有Memcached，Redis，LevelDB等。在通信方面，主要使用专有的二进制协议，这样做的好处是协议解析的的性能比较高，不足的地方在于通用性差，需要为不同的语言实现专门的客户端，开发成本高，同时二进制协议的可调试性差，导致定位问题困难；在架构设计方面，上述存储的分布式基本都需要客户端来实现，Redis从3.0之后开始支持集群，但从生产环境中的测试情况来看，单点故障导致集群不可用的情况依然存在，且Redis的定位是缓存，对于持久化的支持程度有限。

本发明主要是对系统中的分布式组件的功能进行的改进，分布式组件向存储引擎写入数据时，能够根据Key来进行负载均衡，将数据写入指定的存储节点。分布式组件作为客户端与存储引擎之间的反向代理，对客户端屏蔽负载均衡的细节，保证存储节点的http接口的透明性。当某一个存储节点宕机时，HA会自动对数据写请求进行负载均衡，保证整个系统依然可用，从而解决KV存储的单点限制。

另外，分布式组件中的每个节点都是独立的，当某一HA节点宕机时，LVS会自动将数据写请求发送至分布式组件中的其他可用的HA节点，从而解决了HA的单点限制。当需要提高系统的吞吐率时，也只需要简单地增加HA节点即可实现。

数据同步模块在设计上有两种模式，模式一：放在HA的实现中，和HA的master进程耦合在一起(不可能放在worker中，因为Nginx的进程模型是1master-N worker，而数据同步的服务只能存在于一个进程中)。模式二：作为单独的服务，即，将数据同步模块和HA分离。模式一的好处是开发简单，部署简单，缺点是会当数据同步模块崩溃时，会导致HA的master进程一起退出，从而使HA的单节点丧失高可用性，生产环境中这会带来巨大的风险。模式二的好处是服务隔离，进程隔离，HA不再和数据同步模块耦合在一起，两者仅仅通过文件即可协同完成数据同步的功能，当数据同步模块意外退出时，HA的master进程不受影响，服务整体依然可用，缺点是开发和部署的工作量增大。HustDB HA最终选择模式二来完成数据同步模块，这样的设计使得HA的复杂度大大降低，无需关注数据同步的细节，只需要将不一致的数据记录成日志(binlog)即可，在极大程度上提高了HA以及整个存储系统的高可用性，并保证集群数据的最终一致性。

目前业界主流的存储对于replica的实现存在两种模式：

模式一：1Primary-1Replica Shard

模式二：1Primary-N Replica Shards

HustDB HA选用了工程上更加可行的模式一。模式二由于一份数据具有更多的备份，因此具备更高的的可用性，但同时带来了更多的数据一致性问题和实现的复杂度。模式一在高可用性方面不如模式二，但在实现难度方面要小很多，且Hustdb HA自身的定位是分布式KV存储，而不是分布式数据库，因此相对而言，模式一更加适用。

在本发明中，分布式组件可以由Nginx服务器实现，Nginx是高吞吐高并发的http反向代理，由于HustDB HA并不需要对存储节点上的数据进行合并(merge)，因此为了提高系统的吞吐量和并发量，HA的进程模型为1master-N worker，其中master进程会对worker进程进行自动保活，这一点保证了HA单个节点的高可用性和高吞吐性。由于各个进程是独立的，因此对于少部分用到共享数据的接口，需要利用共享内存来进行通信。

Nginx服务器现有的负载均衡策略将存储节点地址等细节完全对外屏蔽了，也就是说，对于开发者来说这些细节是透明的，因此，无法将数据写入指定的存储节点，从而限定了定制化的负载均衡的实现，本发明提供的数据写请求处理方法及装置能够实现定制化的负载均衡，实现将数据写入指定的存储节点。

在上述系统框架下，本发明提供了数据写请求处理方法的几个实施例，该方法基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，对于调用端发送的数据写请求可以通过一个主请求和至少一个子请求完成，主请求可以确定向哪些存储节点写入数据，子请求可以向主请求所确定的存储节点写入数据，可以依据数据要写入存储节点的个数来确定子请求的个数，具体描述如下。

图1示出了根据本发明一个实施例的数据写请求处理方法的流程示意图。如图1所示，该方法包括以下步骤：

步骤S100，对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中。

在本发明实施例中，访问接口指可以访问到全局变量的接口，这里访问全局变量是为了从全局变量中选择待写入数据的存储节点的存储节点地址，以将数据写入到对应的存储节点中，其中，全局变量中存储了存储引擎中所有存储节点的存储节点地址。在调用访问接口从全局变量中选择了待写入数据的存储节点的存储节点地址后，便可以向对应的存储节点发送子请求了，其中将选择的存储节点地址保存至子请求的上下文中，具体地，生成一个子请求对象，将子请求对象与上下文关联起来，即，将子请求对象与上下文绑定在一起。其中，上下文指在一个请求的处理过程中，把一些关键的信息保存下来的类似struct这样的结构体，这里指将选择的存储节点地址保存至子请求的上下文中，以便于在后续方法步骤中获取选择的存储节点地址，根据该存储节点地址与存储节点建立连接。

步骤S101，从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中。

存储节点地址是分布式组件与存储节点建立连接的关键，这里还需要从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中。具体地，子请求的上下文中可能包含了多个信息，每个信息都对应有相应的属性字段，可以根据地址属性字段从子请求的上下文中提取出地址属性字段对应的存储节点地址，并将提取出的存储节点地址保存至存储节点的上下文中。

步骤S102，从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

在将存储节点地址保存至存储节点的上下文之后，便可以在分布式组件与存储节点之间建立连接，具体地，可以从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

根据本发明上述实施例提供的方法，对于一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中，从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中，从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。在本实施例中，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。

图2示出了根据本发明另一个实施例的数据写请求处理方法的流程示意图。在图2所示实施例中将以分布式组件为Nginx服务器为例进行详细介绍。

Nginx服务器是以全异步非阻塞的方式运行，Nginx服务器所执行数据写请求处理方法步骤可以分为Nginx主循环和Nginx子循环(子请求的处理过程)，其中，Nginx主循环包括步骤S200-步骤S203、步骤S208-步骤S209；Nginx子循环包括步骤S204-步骤S207，下面针对各个方法步骤做详细介绍：

步骤S200，在主循环中，调用用于处理子请求的处理器的入口函数。

为了能够实现多个子请求可以自动串行执行，本实施例预先创建用于处理子请求的处理的入口函数addon_handler。一旦进入Nginx主循环中，首先调用用于处理子请求的处理的入口函数addon_handler，利用用于处理子请求的处理器来处理子请求。针对每一个子请求，都需要执行步骤S204-步骤S206，也就是说，当一个子请求执行完后，在回到主循环过程中后，通过调用用于处理子请求的处理器的入口函数，利用用于处理子请求的处理器处理下一个子请求。

步骤S201，获取主请求的上下文。

数据写请求包含主请求和至少一个子请求，主请求的上下文中记录了向哪些存储节点写入数据，这里获取主请求的上下文是为了根据主请求的上下文的记载确定向哪些存储节点发送子请求。

步骤S202，判断主请求的上下文是否已创建，若否，则执行步骤S203；若是，则执行步骤S208。

这里判断主请求的上下文是否创建主要是为了确定对应的数据写请求是否是调用端发起的新的数据写请求。如果是新的数据写请求，对应的主请求的上下文还未创建，需要创建主请求的上下文。判断出主请求的上下文已创建，则说明前面已经处理过该数据写请求，此时需要确定是否已向主请求的上下文中所记录的全部存储节点都写入数据，具体地，可以判断待写入数据的存储节点是否为空。

步骤S203，创建主请求的上下文，并将主请求的上下文与主请求关联。

在判断出主请求的上下文未创建的情况下，可以创建主请求的上下文，将主请求的上下文与主请求关联，具体地，生成一个主请求对象，将主请求对象与上下文关联起来，即，将主请求对象与上下文绑定在一起。

步骤S204，对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中。

本发明中，HA要解决的最重要的问题之一是负载均衡，这是让存储引擎从单点扩充为集群的基础。而支持调用端选择存储节点(Customized Peer Selector)是实现定制化的负载均衡的关键。本实施例方案支持HA往指定的ip:port的存储节点发送子请求，存储节点的地址(uri)是参数化的，可传入的。支持调用端选择存储节点依赖于一系列Nginx内置的数据结构。

本实施例中，当HA加载配置文件时，获取存储节点地址列表相关的配置信息；将存储节点地址列表保存到全局变量中，生成全局变量的访问接口。

在一个具体的实施例中，当HA加载配置文件时，如发现名为customized_selector的上游存储节点的配置项时，会设置初始化函数为ngx_http_peer_selector_init，之后在upstream进行初始化时，会调用此函数，将上游存储节点地址列表保存至全局变量g_peer_selector_backends中，并通过函数ngx_http_get_backends对外提供访问接口。HA通过访问接口ngx_http_get_backends获取到上游存储节点地址列表后，可完成负载均衡表的构建过程。

在调用访问接口从全局变量中选择了待写入数据的存储节点的存储节点地址后，便可以向对应的存储节点发送子请求了，其中将选择的存储节点地址保存至子请求的上下文中，具体地，生成一个子请求对象，将子请求对象与上下文关联起来，即，将子请求对象与上下文绑定在一起。其中，上下文指在一个请求的处理过程中，把一些关键的信息保存下来的类似struct这样的结构体，这里指将选择的存储节点地址保存至子请求的上下文中，以便于在后续方法步骤中获取选择的存储节点地址，根据该存储节点地址与存储节点建立连接。在本步骤中，具体可以通过函数ngx_http_set_addon_module_ctx将选择的存储节点地址保存至子请求的上下文中。

步骤S205，从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中。

存储节点地址是分布式组件与存储节点建立连接的关键，这里还需要从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中。具体地，子请求的上下文中可能包含了多个信息，每个信息都对应有相应的属性字段，可以根据地址属性字段从子请求的上下文中提取出地址属性字段对应的存储节点地址，并将提取出的存储节点地址保存至存储节点的上下文中。在本步骤中，具体可以通过ngx_http_peer_selector_module将之前保存至子请求的上下文中的存储节点地址提取出来，并保存至存储节点的上下文中。

步骤S206，从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

在本步骤中，具体可以通过ngx_http_peer_selector_module将之前保存至存储节点的上下文中的存储节点地址提取出来，通过Nginx服务器的内置函数ngx_http_upstream_connect与存储节点建立连接，例如，TCP连接，将数据写入到相应的存储节点。

步骤S207，调用子请求完成回调函数。

调用子请求完成回调函数，可以回到Nginx主循环过程中，在回到主循环中后，便可以再次调用用于处理子请求的处理器的入口函数，利用用于处理子请求的处理器处理下一个子请求。

由于HustDB HA采用了1Primary-1Replica Shard的存储模式，每次写操作都涉及到对Primary和Replica Shard两个节点的串行访问，这依赖于串行子请求(SequentialSubrequests)的技术实现。串行子请求是Nginx http开发中难度最大的技术点之一。正确进行串行子请求编程的关键，是将上游存储节点选择的控制权从Nginx内核转移到上层，即每一次子请求结束之后，Nginx都会调用子请求完成回调函数回到主循环过程中，在主循环过程中再次调用用于处理子请求的处理器的入口函数，实现了前一个子请求结束之后，让后一个子请求自动发出去，从而将多个子请求串起来自动化。这样Nginx处理器可以决定子请求转发的上游存储节点地址。

本实施例中串行子请求的投递方法并非用常规的for循环方式实现，而是利用创建子请求的状态机模型实现。每一个子请求发出去之后，Nginx将回到主循环中，等待下一个事件的触发。因此所有跨越子请求的上下文，都需要自行保存下来。在本发明的一种可选实施方式中，在将数据写入到相应的存储节点之后，方法还包括：保存子请求的上下文。

步骤S208，判断待写入数据的存储节点是否为空，若是，则执行步骤S209；若否，则执行步骤S204。

这里判断待写入数据的存储节点是否为空，是为了确定待写入数据的存储节点是否已经写入了数据，若待写入数据的存储节点为空，则说明待写入数据的存储节点都已经写入了数据；若待写入数据的存储节点不为空，则说明待写入数据的存储节点还未都写入了数据，需要执行子请求的步骤。

举例说明，假设需要向2个存储节点写入数据，这里判断待写入数据的存储节点是否为空就是要判断这2个存储节点是否都已写入数据，若有一个存储节点还未写入数据，则需要执行子请求的步骤。

步骤S209，向发送数据写请求的调用端返回响应结果。

在存储节点为空的情况下，说明待写入数据的存储节点都已经写入了数据，此时可以向发送数据写请求的调用端返回响应结果，例如，响应结果可以是数据已写入到XX存储节点。

在本发明的一种可选实施方式中，子请求的上下文中定义有状态字段，这里的状态字段标识了数据写请求所处的阶段；将数据写入到相应的存储节点表明一个子请求执行结束，因此，在将数据写入到相应的存储节点之后，还需要更新子请求的上下文的状态字段；用于处理子请求的处理器处理下一个子请求具体为：用于处理子请求的处理器根据更新的状态字段识别出数据写请求所处的阶段，以便处理下一个子请求。

上述可选的实施方式所要解决的问题是在addon_handler中区分当前所处的阶段。对于每一个新的主请求对象，当Nginx第一次调用addon_handler的时候，跟主请求关联的上下文对象是不存在的，利用这个特点可以区分当前是否是第一次调用addon_handler。之后的子请求，就需要更新上下文中定义的状态字段，通过该状态字段的值来判定当前处于什么阶段。上述的流程以上游存储节点是否遍历完毕作为判定标志。当遍历完毕时，可以将处理结果返回给客户端了，串行子请求将终止在这一轮调用。

本实施例的流程中所涉及的关键阶段如下：

1)ngx_http_run_posted_requests是控制整个流程循环的中枢；

2)addon_handler会被ngx_http_core_content_phase所调用，这是Nginx的内容解析阶段；

3)ngx_http_subrequest用于发送子请求，之后会进入反向代理的处理过程ngx_http_proxy_handler；

4)子请求完成后的回调函数会被ngx_http_finalize_request所调用，回调函数需要设置父请求的写事件处理器为ngx_http_core_run_phases，以便Nginx能再次调用到addon_handler。

根据本发明上述实施例提供的方法，一方面，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。另一方面，每一次子请求结束之后，Nginx都会调用子请求完成回调函数回到主循环过程中，在主循环过程中再次调用用于处理子请求的处理器的入口函数，实现了前一个子请求结束之后，让后一个子请求自动发出去，从而将多个子请求串起来自动化，大大提升了数据写请求的处理效率。

图3示出了根据本发明一个实施例的数据写请求处理装置的结构示意图。如图3所示，该装置30包括：用于处理子请求的处理器300；其中，用于处理子请求的处理器300包括：

选择单元301，适于对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址。

子请求处理单元302，适于向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中。

提取单元303，适于从子请求的上下文中提取出所选择的存储节点地址。

上下文写入单元304，适于将提取出的存储节点地址保存至存储节点的上下文中。

连接单元305，适于从存储节点的上下文中提取出存储节点地址，与存储节点建立连接。

数据写入单元306，适于将数据写入到相应的存储节点。

根据本发明上述实施例提供的装置，对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中，从子请求的上下文中提取出所选择的存储节点地址，并保存至存储节点的上下文中，从存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。在本实施例中，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。

图4示出了根据本发明另一个实施例的数据写请求处理装置的结构示意图。与图3相比，不同之处在于，该装置包括：

初始化模块310，适于加载配置文件，获取存储节点地址列表相关的配置信息；将存储节点地址列表保存到全局变量中，生成全局变量的访问接口。

用于处理主请求的处理器320，其中，用于处理主请求的处理器320包括：

获取单元321，适于获取主请求的上下文；

第一判断单元322，适于判断主请求的上下文是否已创建；

创建单元323，适于若主请求的上下文未创建，创建主请求的上下文；

关联单元324，适于将主请求的上下文与主请求关联。

第二判断模块330，适于若主请求的上下文已创建，判断待写入数据的存储节点是否为空；

响应模块340，适于若待写入数据的存储节点为空，向发送数据写请求的调用端返回响应结果；

用于处理子请求的处理器300具体适于在待写入数据的存储节点不为空的情况下运行。

用于处理子请求的处理器还包括：回调单元307，适于调用子请求完成回调函数，回到主循环过程中；

调用模块350，适于在主循环过程中，调用用于处理子请求的处理器的入口函数，利用用于处理子请求的处理器处理下一个子请求。

存储模块360，适于保存子请求的上下文。

其中，子请求的上下文中定义有状态字段；

用于处理子请求的处理器300还包括：更新单元308，适于更新子请求的上下文的状态字段；

用于处理子请求的处理器300具体适于：根据更新的状态字段识别出数据写请求所处的阶段，以便处理下一个子请求。

根据本发明上述实施例提供的装置，一方面，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。另一方面，每一次子请求结束之后，Nginx都会调用子请求完成回调函数回到主循环过程中，在主循环过程中再次调用用于处理子请求的处理器的入口函数，实现了前一个子请求结束之后，让后一个子请求自动发出去，从而将多个子请求串起来自动化，大大提升了数据写请求的处理效率。

图5示出了根据本发明一个实施例的分布式数据存储系统的结构示意图。如图5所示，该系统500包括：调用端510、分布式组件520和存储节点530；其中，分布式组件520包括数据写请求处理装置30。

根据本发明上述实施例提供的系统，一方面，利用全局变量记录存储节点的存储节点地址，而且该全局变量提供有供访问的访问接口，通过调用该访问接口即可获取待写入数据的存储节点的存储节点地址，使存储节点地址暴露出来，从而能够满足调用端的定制化要求向指定存储节点写入数据，实现了定制化的负载均衡，解决了KV存储的单点限制。另一方面，每一次子请求结束之后，Nginx都会调用子请求完成回调函数回到主循环过程中，在主循环过程中再次调用用于处理子请求的处理器的入口函数，实现了前一个子请求结束之后，让后一个子请求自动发出去，从而将多个子请求串起来自动化，大大提升了数据写请求的处理效率。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的数据写请求处理设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了：

A1、一种数据写请求处理方法，所述方法基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，所述方法包括：

对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向所述存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

从子请求的上下文中提取出所选择的存储节点地址，并保存至所述存储节点的上下文中；

从所述存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

A2、根据A1所述的方法，其中，在发送子请求之前，所述方法还包括：

加载配置文件，获取存储节点地址列表相关的配置信息；

将存储节点地址列表保存到所述全局变量中，生成所述全局变量的访问接口。

A3、根据A1或A2所述的方法，其中，在发送子请求之前，所述方法还包括：

获取主请求的上下文；

判断所述主请求的上下文是否已创建；

若所述主请求的上下文未创建，创建所述主请求的上下文，并将所述主请求的上下文与主请求关联。

A4、根据A3所述的方法，其中，在发送子请求之前，所述方法还包括：若所述主请求的上下文已创建，判断待写入数据的存储节点是否为空；若是，则向发送数据写请求的调用端返回响应结果；

若否，则执行发送子请求的步骤。

A5、根据A1-A4中任一项所述的方法，其中，在将数据写入到相应的存储节点之后，所述方法还包括：

调用子请求完成回调函数，回到主循环过程中；

在主循环过程中，调用用于处理子请求的处理器的入口函数，利用所述用于处理子请求的处理器处理下一个子请求。

A6、根据A5所述的方法，其中，在将数据写入到相应的存储节点之后，所述方法还包括：保存所述子请求的上下文。

A7、根据A5所述的方法，其中，所述子请求的上下文中定义有状态字段；

在将数据写入到相应的存储节点之后，所述方法还包括：更新子请求的上下文的状态字段；

所述用于处理子请求的处理器处理下一个子请求具体为：所述用于处理子请求的处理器根据更新的状态字段识别出数据写请求所处的阶段，以便处理下一个子请求。

A8、根据A1-A7中任一项所述的方法，其中，所述方法利用部署在调用端与存储节点之间的分布式组件实现，所述分布式组件为反向代理服务器。

A9、根据A8所述的方法，其中，所述反向代理服务器为Nginx服务器。

B10、一种数据写请求处理装置，所述装置基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，所述装置包括：用于处理子请求的处理器；

所述用于处理子请求的处理器包括：

选择单元，适于对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址；

子请求处理单元，适于向所述存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

提取单元，适于从子请求的上下文中提取出所选择的存储节点地址；

上下文写入单元，适于将提取出的存储节点地址保存至所述存储节点的上下文中；

连接单元，适于从所述存储节点的上下文中提取出存储节点地址，与存储节点建立连接；

数据写入单元，适于将数据写入到相应的存储节点。

B11、根据B10所述的装置，其中，所述装置还包括：初始化模块，适于加载配置文件，获取存储节点地址列表相关的配置信息；将存储节点地址列表保存到所述全局变量中，生成所述全局变量的访问接口。

B12、根据B10或B11所述的装置，其中，所述装置还包括：用于处理主请求的处理器；

所述用于处理主请求的处理器包括：

获取单元，适于获取主请求的上下文；

第一判断单元，适于判断所述主请求的上下文是否已创建；

创建单元，适于若所述主请求的上下文未创建，创建所述主请求的上下文；

关联单元，适于将所述主请求的上下文与主请求关联。

B13、根据B12所述的装置，其中，所述装置还包括：

第二判断模块，适于若所述主请求的上下文已创建，判断待写入数据的存储节点是否为空；

响应模块，适于若待写入数据的存储节点为空，向发送数据写请求的调用端返回响应结果；

所述用于处理子请求的处理器具体适于在待写入数据的存储节点不为空的情况下运行。

B14、根据B10-B13中任一项所述的装置，其中，所述用于处理子请求的处理器还包括：回调单元，适于调用子请求完成回调函数，回到主循环过程中；

所述装置还包括：调用模块，适于在主循环过程中，调用用于处理子请求的处理器的入口函数，利用所述用于处理子请求的处理器处理下一个子请求。

B15、根据B14所述的装置，其中，所述装置还包括：存储模块，适于保存所述子请求的上下文。

B16、根据B14所述的装置，其中，所述子请求的上下文中定义有状态字段；

所述用于处理子请求的处理器还包括：更新单元，适于更新子请求的上下文的状态字段；

所述用于处理子请求的处理器具体适于：根据更新的状态字段识别出数据写请求所处的阶段，以便处理下一个子请求。

B17、根据B10-B16中任一项所述的装置，其中，所述装置利用部署在调用端与存储节点之间的分布式组件实现，所述分布式组件为反向代理服务器。

B18、根据B17所述的装置，其中，所述反向代理服务器为Nginx服务器。

C19、一种分布式数据存储系统，包括：调用端、分布式组件和存储节点；其中，所述分布式组件包括B10-B18中任一项所述的数据写请求处理装置。

Claims (10)

1.一种数据写请求处理方法，所述方法基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，所述方法包括：

对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址，向所述存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

从子请求的上下文中提取出所选择的存储节点地址，并保存至所述存储节点的上下文中；

从所述存储节点的上下文中提取出存储节点地址，与存储节点建立连接，将数据写入到相应的存储节点。

2.根据权利要求1所述的方法，其中，在发送子请求之前，所述方法还包括：

加载配置文件，获取存储节点地址列表相关的配置信息；

将存储节点地址列表保存到所述全局变量中，生成所述全局变量的访问接口。

3.根据权利要求1或2所述的方法，其中，在发送子请求之前，所述方法还包括：

获取主请求的上下文；

判断所述主请求的上下文是否已创建；

若所述主请求的上下文未创建，创建所述主请求的上下文，并将所述主请求的上下文与主请求关联。

4.根据权利要求3所述的方法，其中，在发送子请求之前，所述方法还包括：若所述主请求的上下文已创建，判断待写入数据的存储节点是否为空；若是，则向发送数据写请求的调用端返回响应结果；

若否，则执行发送子请求的步骤。

5.根据权利要求1-4中任一项所述的方法，其中，在将数据写入到相应的存储节点之后，所述方法还包括：

调用子请求完成回调函数，回到主循环过程中；

在主循环过程中，调用用于处理子请求的处理器的入口函数，利用所述用于处理子请求的处理器处理下一个子请求。

6.根据权利要求5所述的方法，其中，在将数据写入到相应的存储节点之后，所述方法还包括：保存所述子请求的上下文。

7.根据权利要求5所述的方法，其中，所述子请求的上下文中定义有状态字段；

在将数据写入到相应的存储节点之后，所述方法还包括：更新子请求的上下文的状态字段；

所述用于处理子请求的处理器处理下一个子请求具体为：所述用于处理子请求的处理器根据更新的状态字段识别出数据写请求所处的阶段，以便处理下一个子请求。

8.根据权利要求1-7中任一项所述的方法，其中，所述方法利用部署在调用端与存储节点之间的分布式组件实现，所述分布式组件为反向代理服务器。

9.一种数据写请求处理装置，所述装置基于调用端发送的数据写请求向存储节点中写入数据，其中数据写请求包含主请求和至少一个子请求，所述装置包括：用于处理子请求的处理器；

所述用于处理子请求的处理器包括：

选择单元，适于对于每一个子请求，调用访问接口从全局变量中选择待写入数据的存储节点的存储节点地址；

子请求处理单元，适于向所述存储节点发送子请求，其中将选择的存储节点地址保存至子请求的上下文中；

提取单元，适于从子请求的上下文中提取出所选择的存储节点地址；

上下文写入单元，适于将提取出的存储节点地址保存至所述存储节点的上下文中；

连接单元，适于从所述存储节点的上下文中提取出存储节点地址，与存储节点建立连接；

数据写入单元，适于将数据写入到相应的存储节点。

10.一种分布式数据存储系统，包括：调用端、分布式组件和存储节点；其中，所述分布式组件包括权利要求9所述的数据写请求处理装置。