CN106803841A - 消息队列数据的读取方法、装置及分布式数据存储*** - Google Patents

Abstract

本发明公开了一种消息队列数据的读取方法、装置及分布式数据存储***。其中，所述方法基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，所述方法包括：获取调用端提供的多个存储节点地址；对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求；接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；向调用端返回合并结果。在本实施例中，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

Description

消息队列数据的读取方法、装置及分布式数据存储***

技术领域

本发明涉及计算机网络技术领域，具体涉及一种消息队列数据的读取方法、装置及分布式数据存储***。

背景技术

在分布式数据存储***中，分布式组件基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，其中，分布式组件为反向代理服务器，具体地，可以为Nginx服务器。

Nginx进行反向代理开发的关键函数是ngx_http_subrequest，该函数的功能是向上游的节点发送一个子请求，并获取数据，然而ngx_http_subrequest有以下的局限性：

ngx_http_subrequest生成子请求依赖于客户端过来的主请求的对象，是上下文相关的代理技术(context-dependent-proxy)，如果没有客户端发送的请求过来，nginx将无法自动生成子请求，这是其最大的局限性。

ngx_http_subrequest本质上利用了ngx_http_proxy_module来实现httpclient的功能。这导致所有基于ngx_http_subrequest实现的功能必须融合到ngx_http_run_posted_requests(nginx的内置函数)所包含的循环之中。

而Nginx本身的设计就是，每处理完一个事件后，将会检查主请求中还有没有已投递的子请求事件，如果有则处理。

因此很难使用如下的直观写法来实现并行子请求：

从而导致读取消息队列数据占用时间长，***可用性低。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的消息队列数据的读取方法、消息队列数据的读取装置和分布式数据存储***。

根据本发明的一个方面，提供了一种消息队列数据的读取方法，方法基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，方法包括：

获取调用端提供的多个存储节点地址；

对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求；

接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；

向调用端返回合并结果。

根据本发明的另一方面，提供了一种消息队列数据的读取装置，装置基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，装置包括：

获取模块，适于获取调用端提供的多个存储节点地址；

构造模块，适于对于每一个存储节点地址，根据存储节点地址构造子请求；

发送模块，适于向存储节点地址对应的存储节点发送子请求；

数据接收模块，适于接收每个存储节点响应子请求而返回的响应数据；

合并处理模块，适于根据预设合并规则对响应数据进行合并处理；

响应模块，适于向调用端返回合并结果。

根据本发明的另一方面，提供了一种分布式数据存储***，包括：调用端、分布式组件和存储节点；其中，分布式组件包括上述消息队列数据的读取装置。

根据本发明提供的方案，获取调用端提供的多个存储节点地址；对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求；接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；向调用端返回合并结果。在本实施例中，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

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

附图说明

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

图1示出了根据本发明一个实施例的消息队列数据的读取方法的流程示意图；

图2示出了根据本发明另一个实施例的消息队列数据的读取方法的流程示意图；

图3示出了根据本发明一个实施例的消息队列数据的读取装置的结构示意图；

图4示出了根据本发明另一个实施例的消息队列数据的读取装置的结构示意图；

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

具体实施方式

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

消息队列是分布式数据存储***中重要组成部分，主要解决应用耦合，异步消息，流量削锋等问题，并实现高性能，高可用，可伸缩和最终一致性架构，是大型分布式数据存储***不可缺少的。

目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ等，在通信方面，主要使用专有的二进制协议，这样做的好处是协议解析的性能比较高，不足的地方在于通用性差，需要为不同的语言实现专门的客户端，开发成本高，同时二进制协议的可调试性差，导致定位问题困难；在架构设计方面，分布式组件和存储引擎基本都是耦合在一个组件中，导致复杂度的增加。以RabbitMQ为例，由于其架构设计上的问题，导致在真实的生产环境中，一旦集群中的某一个节点宕机，基本都会导致整个集群不可用，从而退化成单点依赖；而集群恢复后，装载数据的过程需要冗长的时间，进一步降低***的可用性。

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

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

分布式组件作为调用端与存储引擎之间的反向代理，对调用端屏蔽负载均衡的细节，保证存储节点的http接口的透明性。当某一个存储节点宕机时，HA会自动对调用请求进行负载均衡，保证整个***依然可用，从而解决消息队列存储上的单点限制。

本发明主要是对***中的分布式组件的功能进行的改进，分布式组件可以由Nginx服务器实现，Nginx服务器是业界性能最高的http反向代理服务器之一，具备一流的并发能力。其master-worker架构保证了，当某一个worker意外退出时，master会自动再启动一个worker进程，这一点保证了HA单个节点的高可用性，无需人工对服务进行保活。另外，分布式组件基于Nginx开发，独立部署，对外提供http的接口，保证了通信协议的跨语言，跨平台，并方便调试。

另外，分布式组件中的每个节点都是独立的，当某一HA节点宕机时，LVS会自动将调用请求发送至分布式组件中的其他可用的HA节点，从而解决了HA的单点限制。此外，当需要提高***的吞吐率时，也只需要简单地增加HA节点即可实现，使得整个***可以进行平滑的扩容。

分布式组件支持以下两种负载均衡策略：轮询(Round Robin)和按队列名哈希(Queue Hash)其中，使用Round Robin的好处在于，即使某一台存储节点宕机，HA也会自动将调用请求代理到下一个可用的节点，这样保证服务整体依然是可用的，不足的地方在于同一个队列的数据会分散存储在多个节点上，对于需要严格FIFO(先进先出)的业务不适用；使用Queue Hash的好处在于，针对确定的队列名，其存储节点是固定的，而非分散的，因此可以严格保证队列数据的FIFO特性，不足的地方在于，如果某一台存储节点宕机，那么按队列名哈希到这个节点的数据将无法存储，从而使得服务部分不可用。

分布式组件中进程模型采用了1master-1worker的模型。Nginx支持1master-Nworkers的进程模型，但这样做的代价在于，由于各个进程是独立的，因此对于共享数据，需要利用共享内存来进行通信。分布式组件需要定期从存储消息队列数据的存储节点上读取数据，并进行合并(merge)。如果使用1master-N workers的模型，必然要对共享内存进行加锁，这一方面降低了***的性能，另一方面加大了实现的复杂度。因此最终选用了实现起来代价最小，性能相对优秀的1master-1worker模型。

在上述***框架下，本发明提供了消息队列数据的读取方法的几个实施例，该方法基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，具体描述如下。

图1示出了根据本发明一个实施例的消息队列数据的读取方法的流程示意图。如图1所示，该方法包括以下步骤：

步骤S100，获取调用端提供的多个存储节点地址。

存储节点地址是存储节点的一种标识，具有唯一性，当调用端期望从存储消息队列数据的存储节点中读取数据时，需要提供存储节点地址，以根据存储节点地址确定从哪些存储节点读取消息队列数据，一般情况下，同一个消息队列的数据会分散存储在多个存储节点上，也就是说，调用端将提供多个存储节点地址，这里需要获取到调用端提供的多个存储节点地址。

步骤S101，对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求。

在本步骤中，根据获取到的每一个存储节点地址来构造子请求，所构造的子请求的上下文与调用请求的上下文无关，并且每个子请求的上下文与其他子请求的上下文也无关。由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

步骤S102，接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理。

存储节点在接收到子请求后，将根据子请求而向分布式组件返回相应的响应数据，分布式组件接收每个存储节点响应子请求而返回的响应数据，由于同一个消息队列的数据会分散存储在多个存储节点上，因此在接收到响应数据之后，还需要根据预设合并规则对响应数据进行合并处理。

步骤S103，向调用端返回合并结果。

具体地，在对响应数据进程合并处理之后，向调用端返回合并结果。

根据本发明上述实施例提供的方法，获取调用端提供的多个存储节点地址；对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求；接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；向调用端返回合并结果。在本实施例中，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

图2示出了根据本发明另一个实施例的消息队列数据的读取方法的流程示意图。如图2所示，该方法包括以下步骤：

步骤S200，获取调用端提供的多个存储节点地址。

存储节点地址是存储节点的一种标识，具有唯一性，当调用端期望从存储消息队列数据的存储节点中读取数据时，需要提供存储节点地址，以根据存储节点地址确定从哪些存储节点读取消息队列数据，一般情况下，同一个消息队列的数据会分散存储在多个存储节点上，也就是说，调用端将提供多个存储节点地址，这里需要获取到调用端提供的多个存储节点地址。

步骤S201，建立与存储节点地址对应的存储节点的Keepalive连接。

存储节点地址又是分布式组件与存储节点建立连接的关键，分布式组件在获取到存储节点地址后，才可以根据存储节点地址与对应的存储节点建立连接。在本发明实施例中，分布式组件需要根据存储节点地址建立与对应的存储节点的Keepalive连接。具体地，ngx_http_fetch_cache定义了存储节点的Keepalive的连接池。

步骤S202，对于每一个存储节点地址，根据存储节点地址构造子请求。

在本发明实施例中，分布式组件需要实现的一个重要的功能是周期性地从存储节点读取队列的数据进行合并，对客户端屏蔽分布式存储的细节。要实现这样的功能，需要用到上下文无关的反向代理技术(context-free-proxy)，该技术也是实现并行子请求(parallel subrequests)的关键。

在本步骤中，根据获取到的每一个存储节点地址来构造子请求，所构造的子请求的上下文与调用请求的上下文无关，并且每个子请求的上下文与其他子请求的上下文也无关。

在一个具体的示例中，当需要向存储节点发起子请求时，利用ngx_http_fetch函数根据获取到的多个存储节点地址自动构造多个请求，实现上下文无关(context-free-proxy)。ngx_http_fetch在发起子请求时并不依赖于nginx内置的ngx_http_subrequest函数，因此也便脱离了ngx_http_run_posted_requests所带来的限制，从而可以用以下直观的方式实现并行子请求(parallel subrequests)：

实现并行子请求具有如下优点：当需要访问的存储节点的数量为n时，假设各个存储节点的请求延时(Latency)分别为(T1,T2...Tn)，那么串行子请求所需要的总开销为sum(T1,T2...Tn)，而并行子请求的总开销则为max(T1,T2...Tn)，从而大大提高了***的吞吐量。

步骤S203，对子请求进行编码处理。

在根据存储节点地址构造子请求之后，需要对子请求进行编码处理，具体地，可以通过ngx_http_fetch_encode对发送给子请求进行编码处理。

步骤S204，将经过编码处理的子请求发送至存储节点地址对应的存储节点。

在对子请求进行编码处理后，可以将经过编码处理的子请求并行发送至存储节点地址对应的存储节点，从而节省了读取数据所需时间，大大提高了***的吞吐量。

步骤S205，接收每个存储节点响应子请求而返回的响应数据。

存储节点在接收到子请求后，将根据子请求而向分布式组件返回相应的响应数据，分布式组件接收每个存储节点响应子请求而返回的响应数据。

步骤S206，对响应数据进行解码处理。

在接收到存储节点返回的响应数据后，还需要对响应数据进行解码处理，具体地，可以通过ngx_http_fetch_decode对接收到的响应数据进行解码处理。

步骤S207，根据预设合并规则对响应数据进行合并处理。

由于同一个消息队列的数据会分散存储在多个存储节点上，因此在接收到响应数据之后，还需要根据预设合并规则对响应数据进行合并处理。

具体地，可以将接收到的多个存储节点返回的响应数据进行合并处理，举例说明，假如调用端提供了三个存储节点地址，分别为第一存储节点、第二存储节点和第三存储节点，这里就是将接收到的三个存储节点返回的响应数据合并到一起。

另外，本发明实施例还可以将接收到的多个存储节点返回的响应数据中的元数据进行合并处理。其中，元数据为响应数据的描述信息，这里主要是描述响应数据的属性，具体可以包括以下一种或多种信息的组合：队列类形、队列最大消息个数、队列是否被锁定、超出时间。在本发明实施例中，元数据的每个字段又有其各自的合并规则，举例说明，超出时间的合并规则是取最大值；队列最大消息个数则有其特殊规定，合并规则为取最小值，这里仅仅是举例说明，不具有任何限定作用。

步骤S208，向调用端返回合并结果。

具体地，在对响应数据进程合并处理之后，向调用端返回合并结果。

在本发明一种可选实施方式中，调用端具体可以为客户端；在获取调用端提供的多个存储节点地址之前，方法还包括：接收客户端发送的主请求，主请求中携带有多个存储节点地址，分布式组件可以从主请求中获取多个存储节点地址；然后根据存储节点地址构造子请求，其中，子请求的上下文与主请求的上下文无关。

在本发明另一种可选实施方式中，调用端根据定时器的定时任务触发调用请求，定时器可以设定调用端触发调用请求的时机，到达定时器设定的时间后，调用端触发调用请求，以从存储消息队列的存储节点拉取数据，调用端在获取到数据后，可以将数据推送给客户端，当然也可以暂时存储在调用端侧，在接收到客户端的请求之后发送至客户端。

根据本发明上述实施例提供的方法，在获取到调用端提供的多个存储节点地址后，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

图3示出了根据本发明一个实施例的消息队列数据的读取装置的结构示意图。如图3所示，该装置300包括：获取模块301、构造模块302、发送模块303、数据接收模块304、合并处理模块305、响应模块306。

获取模块301，适于获取调用端提供的多个存储节点地址。

构造模块302，适于对于每一个存储节点地址，根据存储节点地址构造子请求。

发送模块303，适于向存储节点地址对应的存储节点发送子请求。

数据接收模块304，适于接收每个存储节点响应子请求而返回的响应数据。

合并处理模块305，适于根据预设合并规则对响应数据进行合并处理。

响应模块306，适于向调用端返回合并结果。

在图3中仅示出一个存储节点，用于示例性说明。

根据本发明上述实施例提供的装置，获取调用端提供的多个存储节点地址；对于每一个存储节点地址，根据存储节点地址构造子请求，并向存储节点地址对应的存储节点发送子请求；接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；向调用端返回合并结果。在本实施例中，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

图4示出了根据本发明另一个实施例的消息队列数据的读取装置的结构示意图。如图4所示，该装置400包括：获取模块401、连接模块402、构造模块403、编码处理模块404、发送模块405、数据接收模块406、解码处理模块407、合并处理模块408、响应模块409。

获取模块401，适于获取调用端提供的多个存储节点地址。

存储节点地址是存储节点的一种标识，具有唯一性，当调用端期望从存储消息队列数据的存储节点中读取数据时，需要提供存储节点地址，以根据存储节点地址确定从哪些存储节点读取消息队列数据，一般情况下，同一个消息队列的数据会分散存储在多个存储节点上，也就是说，调用端将提供多个存储节点地址，这里需要获取到调用端提供的多个存储节点地址。

连接模块402，适于建立与存储节点地址对应的存储节点的Keepalive连接。

存储节点地址又是分布式组件与存储节点建立连接的关键，分布式组件在获取到存储节点地址后，才可以根据存储节点地址与对应的存储节点建立连接。在本发明实施例中，分布式组件需要根据存储节点地址建立与对应的存储节点的Keepalive连接。具体地，ngx_http_fetch_cache定义了存储节点的Keepalive的连接池。

构造模块403，适于对于每一个存储节点地址，根据存储节点地址构造子请求。

这里是根据获取到的每一个存储节点地址来构造子请求，而不是基于调用端的调用请求来构造子请求，由此实现了子请求的上下文与调用请求的上下文无关，每个子请求的上下文与其他子请求的上下文也无关。

在一个具体的示例中，当需要向存储节点发起子请求时，利用ngx_http_fetch函数根据获取到的多个存储节点地址自动构造多个请求，实现上下文无关(context-free-proxy)。ngx_http_fetch在发起子请求时并不依赖于nginx内置的ngx_http_subrequest函数，因此也便脱离了ngx_http_run_posted_requests所带来的限制，从而可以用以下直观的方式实现并行子请求(parallel subrequests)：

实现并行子请求具有如下优点：当需要访问的存储节点的数量为n时，假设各个存储节点的请求延时(Latency)分别为(T1,T2...Tn)，那么串行子请求所需要的总开销为sum(T1,T2...Tn)，而并行子请求的总开销则为max(T1,T2...Tn)，从而大大提高了***的吞吐量。

编码处理模块404，适于对子请求进行编码处理。

在根据存储节点地址构造子请求之后，需要对子请求进行编码处理，具体地，可以通过ngx_http_fetch_encode对发送给子请求进行编码处理。

发送模块405，适于将经过编码处理的子请求发送至存储节点地址对应的存储节点。

在对子请求进行编码处理后，可以将经过编码处理的子请求并行发送至存储节点地址对应的存储节点，从而节省了读取数据所需时间，大大提高了***的吞吐量。

数据接收模块406，适于接收每个存储节点响应子请求而返回的响应数据。

存储节点在接收到子请求后，将根据子请求而向分布式组件返回相应的响应数据，分布式组件接收每个存储节点响应子请求而返回的响应数据。

解码处理模块407，适于对响应数据进行解码处理。

在接收到存储节点返回的响应数据后，还需要对响应数据进行解码处理，具体地，可以通过ngx_http_fetch_decode对接收到的响应数据进行解码处理。

合并处理模块408，适于根据预设合并规则对响应数据进行合并处理。

在本发明一种可选实施方式中，合并处理模块408进一步适于：将接收到的多个存储节点返回的响应数据进行合并处理。举例说明，假如调用端提供了三个存储节点地址，分别为第一存储节点、第二存储节点和第三存储节点，这里就是将接收到的三个存储节点返回的响应数据合并到一起。

在本发明一种可选实施方式中，合并处理模块408进一步适于：将接收到的多个存储节点返回的响应数据中的元数据进行合并处理。其中，元数据为响应数据的描述信息，这里主要是描述响应数据的属性，具体可以包括以下一种或多种信息的组合：队列类形、队列最大消息个数、队列是否被锁定、超出时间。在本发明实施例中，元数据的每个字段又有其各自的合并规则，举例说明，超出时间的合并规则是取最大值；队列最大消息个数则有其特殊规定，合并规则为取最小值，这里仅仅是举例说明，不具有任何限定作用。

响应模块409，适于向调用端返回合并结果。

在本发明一种可选实施方式中，调用端具体为客户端；此时，装置还包括：主请求接收模块，适于接收客户端发送的主请求，主请求中携带有多个存储节点地址；分布式组件可以从主请求中获取多个存储节点地址，然后根据存储节点地址构造子请求，其中，子请求的上下文与主请求的上下文无关。

在本发明一种可选实施方式中，调用端根据定时器的定时任务触发调用请求，定时器可以设定调用端触发调用请求的时机，到达定时器设定的时间后，调用端触发调用请求，以从存储消息队列的存储节点拉取数据，调用端在获取到数据后，可以将数据推送给客户端，当然也可以暂时存储在调用端侧，在接收到客户端的请求之后发送至客户端。

在本发明实施例中，该装置利用部署在调用端与存储节点之间的分布式组件实现，分布式组件为反向代理服务器。其中，反向代理服务器为Nginx服务器。

在图4中仅示出一个存储节点，用于示例性说明。

根据本发明上述实施例提供的装置，在获取到调用端提供的多个存储节点地址后，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

图5示出了根据本发明一个实施例的分布式数据存储***的结构示意图。如图5所示，该***500包括：调用端510、分布式组件520和存储节点530；其中，分布式组件包括消息队列数据的读取装置400。

传统的进程池的实现中，所有Worker进程分布在同一台机器上，具有单点限制。而在本分布式数据存储***中，分布式组件包括由多个Worker进程组成的分布式进程池；分布式组件提供的do_get和do_post接口可以配合实现基于http的分布式进程池，具体的工作流程如下：

1)Worker进程，适于向分布式组件发送POST请求以认领任务，POST请求被分布式组件阻塞，Worker进程会等待任务过来；

2)客户端，适于向分布式组件发送GET请求以投递任务，GET请求被分布式组件阻塞，客户端会等待任务的处理结果。

3)分布式组件，适于将客户端投递的任务分发给Worker进程进行处理。

4)Worker进程将任务处理完毕，通过do_post接口返回处理结果。

5)分布式组件将处理结果转发给客户端。

以上过程，如果站在客户端的视角，整个任务的处理过程是同步的，因此客户端可以用同步调用的方式使用消息队列，无需维护自己的上下文，从而简化代码的编写方式；如果站在Worker进程的视角，其表现行为和传统的进程池的Worker进程非常类似，而且没有单机的限制，也没有语言的限制，在实现上足够灵活，部署上足够简单，各个Worker进程的实现可以不必局限于一种特定的语言，只需要按照do_post接口的规范进行调用即可。这样的设计提供了一种全新的并行分布式任务处理模型。

下面是对do_get接口的规范和do_post接口的规范的说明：

根据本发明上述实施例提供的***，在获取到调用端提供的多个存储节点地址后，根据存储节点地址构造子请求，实现了子请求的上下文与调用请求的上下文无关，由此便可以并行地向存储节点地址对应的存储节点发送子请求，从而节省了读取数据所需时间，大大提高了***的吞吐量。

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

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

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

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

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

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

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

Claims (10)

1.一种消息队列数据的读取方法，所述方法基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，所述方法包括：

获取调用端提供的多个存储节点地址；

对于每一个存储节点地址，根据所述存储节点地址构造子请求，并向所述存储节点地址对应的存储节点发送所述子请求；

接收每个存储节点响应子请求而返回的响应数据，并根据预设合并规则对响应数据进行合并处理；

向所述调用端返回合并结果。

2.根据权利要求1所述的方法，其中，所述调用端具体为客户端；

所述方法还包括：接收客户端发送的主请求，所述主请求中携带有多个存储节点地址；

所述子请求的上下文与所述主请求的上下文无关。

3.根据权利要求1所述的方法，其中，所述调用端根据定时器的定时任务触发调用请求。

4.根据权利要求1所述的方法，其中，所述根据预设合并规则对响应数据进行合并处理进一步包括：将接收到的多个存储节点返回的响应数据进行合并处理。

5.根据权利要求1或4所述的方法，其中，所述根据预设合并规则对响应数据进行合并处理进一步包括：将接收到的多个存储节点返回的响应数据中的元数据进行合并处理。

6.根据权利要求1-5任一项所述的方法，其中，在向所述存储节点地址对应的存储节点发送所述子请求之前，所述方法还包括：对所述子请求进行编码处理；

所述向所述存储节点地址对应的存储节点发送所述子请求进一步包括：将经过编码处理的子请求发送至所述存储节点地址对应的存储节点。

7.根据权利要求1-6任一项所述的方法，其中，在根据预设合并规则对响应数据进行合并处理之前，所述方法还包括：对所述响应数据进行解码处理。

8.根据权利要求1-7任一项所述的方法，其中，在向所述存储节点地址对应的存储节点发送所述子请求之前，所述方法还包括：

建立与所述存储节点地址对应的存储节点的Keepalive连接。

9.一种消息队列数据的读取装置，所述装置基于调用端的调用请求从存储消息队列数据的存储节点中读取数据，所述装置包括：

获取模块，适于获取调用端提供的多个存储节点地址；

构造模块，适于对于每一个存储节点地址，根据所述存储节点地址构造子请求；

发送模块，适于向所述存储节点地址对应的存储节点发送所述子请求；

数据接收模块，适于接收每个存储节点响应子请求而返回的响应数据；

合并处理模块，适于根据预设合并规则对响应数据进行合并处理；

响应模块，适于向所述调用端返回合并结果。

10.一种分布式数据存储***，包括：调用端、分布式组件和存储节点；其中，所述分布式组件包括权利要求9所述的消息队列数据的读取装置。