用于分布式数据处理的方法和设备与流程

本公开的实施例总体涉及数据处理，具体涉及一种用于分布式数据处理的方法和设备。

背景技术：

分布式数据处理系统或者尤其是实时流系统正变得越来越流行。现代实时流系统，诸如storm、pivotalspringx、sparkstreaming、samza等被广泛地应用于电子商务、大数据分析、数据抽取转换加载(etl)中。提供可靠处理能力是相当普遍和重要的，以使得即使在节点或联网中存在故障也能保证每个消息得以被处理。这种分布式系统的一个关键挑战在于如何在最低成本和最小性能影响的情况下以高效的方式来检测系统中存在的故障，尤其对于具有成千上万个节点和节点间的互连的大型系统。

现有技术中通常存在如下的方法以解决上述问题。一种方法是针对每个发出的消息从每个处理节点向跟踪任务报告状态，然后该跟踪任务通过跟踪每个发出的消息以及节点间的关系来维护该状态；在给定的超时设置的情况下，每个导出的消息将被处理。这种方法是直接的但是低效的，对于每个输入的消息每个节点将遭受额外的报告流量，并且跟踪任务的逻辑将会十分复杂导致其可能消耗大量中央处理单元(cpu)和存储器资源。如以下将结合图2进行描述的，另一种改进的方法被称为基于异或(xor)的算法，该算法能够大大降低跟踪任务的复杂性和所消耗的存储器资源，但是仍然存在可扩展性限制、网络流量上的大量开销、端到端的延迟等各种问题。

因此，本领域中需要一种更有效和更具可扩展性的方法来解决上述问题。

技术实现要素：

本公开的实施例旨在提供一种用于分布式数据处理的方法和设备。

根据本公开的第一方面，提供了一种用于在当前节点处的分布式数据处理的方法，包括：从一个或多个上游节点接收附接有共享计数的一个或多个输入消息，其中所述共享计数被用于确定与所述一个或多个输入消息相关联的根消息的处理状态；处理所述一个或多个输入消息以生成一个或多个新消息；基于接收到的所述共享计数，向每个新消息分配新共享计数；以及向一个或多个下游节点发送附接有相应的新共享计数的所述一个或多个新消息。

在一些实施例中，当所述当前节点为根节点时，从所述一个或多个上游节点接收附接有共享计数的一个或多个输入消息包括：接收从外部进入的所述根消息；以及为所述根消息分配预定的共享计数。

在一些实施例中，所述方法还包括：响应于接收到从外部进入的所述根消息，向跟踪任务报告第一状态信息。

在一些实施例中，所述第一状态信息包括所述根消息的标识符、所述预定的共享计数以及第一操作码，其中所述第一操作码用于向所述跟踪任务指示所述预定的共享计数要被添加。

在一些实施例中，所述方法还包括：当所述当前节点为叶节点时，响应于从所述一个或多个上游节点接收到附接有所述共享计数的所述一个或多个输入消息，向跟踪任务报告第二状态信息。

在一些实施例中，所述第二状态信息包括根消息的标识符、所述叶节点接收到的所述共享计数以及第二操作码，其中所述第二操作码用于向所述跟踪任务指示所述共享计数要被减除。

在一些实施例中，基于接收到的所述共享计数，向每个新消息分配新共享计数包括：基于在所述当前节点处配置的分配策略，向每个新消息分配新共享计数。

在一些实施例中，所述分配策略包括以下的至少一种：基于所述一个或多个下游节点的个数，将所述共享计数平均分配给每个新消息； 以及利用每个下游节点的权重来向每个新消息分配新共享计数。

在一些实施例中，基于接收到的所述共享计数，向每个新消息分配新共享计数包括：向所述共享计数添加附加的共享计数，以利用添加后的总共享计数向每个新消息分配新共享计数。

在一些实施例中，所述方法还包括：响应于向所述共享计数添加所述附加的共享计数，向跟踪任务报告第三状态信息。

在一些实施例中，所述第三状态信息包括根消息的标识符、所述附加的共享计数以及第三操作码，其中所述第三操作码用于向所述跟踪任务指示所述附加的共享计数要被添加。

根据本公开的第二方面，提供了一种用于分布式数据处理的方法，包括：从根节点和叶节点接收与根消息相关联的状态信息；基于从所述状态信息中提取的操作码，对包括在所述状态信息中的共享计数进行处理，以确定对应于所述根消息的总共享计数；以及基于所述总共享计数，确定所述根消息的处理状态。

在一些实施例中，从根节点和叶节点接收与根消息相关联的状态信息包括：从所述根节点接收第一状态信息，其中所述第一状态信息包括所述根消息的标识符、为所述根消息分配的预定的共享计数以及第一操作码；以及从所述叶节点接收第二状态信息，其中所述第二状态信息包括所述根消息的标识符、所述叶节点接收到的共享计数以及第二操作码。

在一些实施例中，基于从所述状态信息中提取的操作码，对包括在所述状态信息中的共享计数进行处理，以确定对应于所述根消息的总共享计数包括：基于所述第一操作码，向所述总共享计数添加为所述根消息分配的所述预定的共享计数；以及基于所述第二操作码，从所述总共享计数中减除所述叶节点接收到的所述共享计数。

在一些实施例中，与所述根消息相对应的所述总共享计数的初始值被设定为零，并且基于所述总共享计数，确定所述根消息的处理状态包括：响应于所述总共享计数为零，确定所述根消息被成功处理；以及响应于所述总共享计数不为零，确定在所述根消息的处理中发生 故障。

在一些实施例中，所述方法还包括：从添加附加共享计数的节点接收第三状态信息，其中所述第三状态信息包括所述根消息的标识符、所述附加共享计数以及第三操作码。

在一些实施例中，基于从所述状态信息中提取的操作码，对包括在所述状态信息中的共享计数进行处理，以确定对应于所述根消息的总共享计数包括：基于所述第三操作码，向所述总共享计数添加所述附加共享计数。

根据本公开的第三方面，提供了一种用于在当前节点处的分布式数据处理的设备，包括：消息接收装置，被配置为从一个或多个上游节点接收附接有共享计数的一个或多个输入消息，其中所述共享计数被用于确定与所述一个或多个输入消息相关联的根消息的处理状态；消息处理装置，被配置为处理所述一个或多个输入消息以生成一个或多个新消息；共享计数分配装置，被配置为基于接收到的所述共享计数，向每个新消息分配新共享计数；以及消息发送装置，被配置为向一个或多个下游节点发送附接有相应的新共享计数的所述一个或多个新消息。

在一些实施例中，当所述当前节点为根节点时，所述消息接收装置被配置为：接收从外部进入的所述根消息；以及为所述根消息分配预定的共享计数。

在一些实施例中，所述设备还包括：第一报告装置，被配置为响应于接收到从外部进入的所述根消息，向跟踪任务报告第一状态信息。

在一些实施例中，所述第一状态信息包括所述根消息的标识符、所述预定的共享计数以及第一操作码，其中所述第一操作码用于向所述跟踪任务指示所述预定的共享计数要被添加。

在一些实施例中，所述设备还包括：第二报告装置，被配置为当所述当前节点为叶节点时，响应于从所述一个或多个上游节点接收到附接有所述共享计数的所述一个或多个输入消息，向跟踪任务报告第二状态信息。

在一些实施例中，所述第二状态信息包括根消息的标识符、所述叶节点接收到的所述共享计数以及第二操作码，其中所述第二操作码用于向所述跟踪任务指示所述共享计数要被减除。

在一些实施例中，所述共享计数分配装置被配置为：基于在所述当前节点处配置的分配策略，向每个新消息分配新共享计数。

在一些实施例中，所述分配策略包括以下的至少一种：基于所述一个或多个下游节点的个数，将所述共享计数平均分配给每个新消息；以及利用每个下游节点的权重来向每个新消息分配新共享计数。

在一些实施例中，所述共享计数分配装置被配置为：向所述共享计数添加附加的共享计数，以利用添加后的总共享计数向每个新消息分配新共享计数。

在一些实施例中，所述设备还包括：第三报告装置，被配置为响应于向所述共享计数添加所述附加的共享计数，向跟踪任务报告第三状态信息。

在一些实施例中，所述第三状态信息包括根消息的标识符、所述附加的共享计数以及第三操作码，其中所述第三操作码用于向所述跟踪任务指示所述附加的共享计数要被添加。

根据本公开的第四方面，提供了一种用于分布式数据处理的设备，包括：第一信息接收装置，被配置为从根节点和叶节点接收与根消息相关联的状态信息；共享计数处理装置，被配置为基于从所述状态信息中提取的操作码，对包括在所述状态信息中的共享计数进行处理，以确定对应于所述根消息的总共享计数；以及状态确定装置，被配置为基于所述总共享计数，确定所述根消息的处理状态。

在一些实施例中，所述第一信息接收装置被配置为：从所述根节点接收第一状态信息，其中所述第一状态信息包括所述根消息的标识符、为所述根消息分配的预定的共享计数以及第一操作码；以及从所述叶节点接收第二状态信息，其中所述第二状态信息包括所述根消息的标识符、所述叶节点接收到的共享计数以及第二操作码。

在一些实施例中，所述共享计数处理装置被配置为：基于所述第 一操作码，向所述总共享计数添加为所述根消息分配的所述预定的共享计数；以及基于所述第二操作码，从所述总共享计数中减除所述叶节点接收到的所述共享计数。

在一些实施例中，与所述根消息相对应的所述总共享计数的初始值被设定为零，并且所述状态确定装置被配置为：响应于所述总共享计数为零，确定所述根消息被成功处理；以及响应于所述总共享计数不为零，确定在所述根消息的处理中发生故障。

在一些实施例中，所述设备还包括：第二信息接收装置，被配置为从添加附加共享计数的节点接收第三状态信息，其中所述第三状态信息包括所述根消息的标识符、所述附加共享计数以及第三操作码。

在一些实施例中，所述共享计数处理装置被配置为：基于所述第三操作码，向所述总共享计数添加所述附加共享计数。

根据本公开的第五方面，提供了一种用于分布式数据处理的计算机程序产品，所述计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，所述计算机可执行指令在被执行时使得计算机执行所述方法中的任一种方法的任意步骤。

与现有技术相比，根据本公开的实施例的用于分布式数据处理的方法和设备，能够有效降低网络流量上的开销以及所消耗的cpu和存储器资源，并且针对不同分布式数据处理系统的拓扑结构具有可扩展性。

附图说明

在此所述的附图用来提供对本公开的进一步理解，构成本公开的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中:

图1图示了分布式数据处理系统的示例性拓扑结构；

图2图示了使用基于异或的算法来进行分布式数据处理的示意图；

图3图示了根据本公开的实施例来进行分布式数据处理的示意图；

图4图示了根据本公开的实施例来进行分布式数据处理的示意图；

图5图示了根据本公开的实施例的用于在当前节点处的分布式数据处理的方法500的流程图；

图6图示了根据本公开的实施例的用于分布式数据处理的方法600的流程图；

图7图示了根据本公开的实施例的用于在当前节点处的分布式数据处理的设备700的框图；

图8图示了根据本公开的实施例的用于分布式数据处理的设备800的框图；以及

图9图示了适于实现本公开的实施例的计算机系统900的框图。

在各个附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

在下文中，将参考附图详细描述本公开的各个示例性实施例。应当注意，这些附图和描述涉及的仅仅是作为示例性的实施例。应该指出的是，根据随后描述，很容易设想出此处公开的结构和方法的替换实施例，并且可以在不脱离本公开要求保护的原理的情况下使用这些替代实施例。

应当理解，给出这些示例性实施例仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。

在此使用的术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。

图1图示了分布式数据处理系统的示例性拓扑结构。

为了便于以下的描述，这里首先给出几个关于分布式数据处理系统的概念的解释：

·拓扑结构

应用通常具有运行为有向无环图(dag)的拓扑结构。拓扑结构 中运行特定逻辑的节点被实现为进程或者线程并且被部署在一个或多个主机中；拓扑结构中的边表示要处理的消息。父节点和下游节点是发布-订阅的关系。更多的节点能够被添加以用于平衡或性能扩展和/或处理流水线。存在两种类型的用于不同角色的节点：根节点和工作节点。

·根节点

任务初始地从外部源摄取消息，外部源诸如消息队列、日志或数据库等。在此将摄取的原始消息称为根消息。根消息将首先进入根节点。通常，一个拓扑结构具有一个根节点，其可以具有或者不具有处理逻辑。然后，根节点将生成的新消息分发给下游的工作节点。

·工作节点

工作节点处理输入消息并且通常生成新消息。节点间的消息分发根据诸如随机、置乱、哈希划分等需求是可配置的。通常，工作节点是内存中处理并且除了叶节点之外不具有中间数据持久性，叶节点不生成新消息并且可选地将最终结果存储在诸如数据库或分布式文件系统的持久存储库中。

·跟踪任务

跟踪任务是用于跟踪根消息的处理状态以及如性能等其他系统级状态的集中式监控任务。

如图1所示，例如，示例性分布式数据系统的拓扑结构可以包括根节点0和工作节点1-9。根消息a可以从外部的消息队列进入拓扑结构中的根节点0。根节点0可以将生成的新消息b和c分别下发给工作节点1和2，工作节点1和2可以继续将生成的新消息下发给各自的下游节点，直到消息到达叶节点8和9。叶节点8和9可以将处理的最终结果存储在数据存储库中。跟踪任务可以用于跟踪包括a在内的根消息的处理状态。应当理解，图1所示出的分布式数据处理系统的拓扑结构仅为示例性的，其中示出的节点和/或消息的数量仅出于简化说明的目的而不一定代表分布式数据处理系统中的实际情况。此外，应当理解，同样出于简化的目的，图1仅示出了分布式数据处理 系统中与本公开的实施例有关的部件，而非分布式数据处理系统中的全部部件。

关于对分布式数据处理系统的消息的可靠处理，存在两种方式：一种方式被称为“恰好一次”，即消息恰好被处理一次，这是一种理想情况；另一种方式被称为“至少一次”，即消息可能被处理多于一次。在实践中，“至少一次”是更加可行的(一旦检测到故障，则仅重新发送数据并且重做所有事)，这种做法对于一些应用是可接受的(即，幂等性)而对于其他应用可能是不可接受的。对于后者，当在叶节点处保存结果时，应用将构建逻辑以检测是否存在任何重复并且对于重复采取诸如丢弃的动作。

然而，无论对于哪种方式，一个关键挑战在于如何在最低成本和最小性能影响的情况下以可靠和可扩展的方式来检测处理故障，尤其考虑到可能存在成千上万或者更多的节点以及端到端的响应时间。

如以上描述的，现有技术中解决上述问题的一种方法是针对每个发出的消息从每个处理节点向跟踪任务报告状态，然后该跟踪任务通过跟踪每个发出的消息以及节点间的关系来维护该状态；在给定的超时设置的情况下，每个导出的消息将被处理。这种方法是直接的但是低效的，对于每个输入的消息每个节点将遭受额外的报告流量，并且跟踪任务的逻辑将会十分复杂导致其可能消耗大量中央处理单元和存储器资源。另一种改进的方法被称为基于异或(xor)的可靠性检测算法。

图2图示了使用基于异或的算法来进行分布式数据处理的示意图。为了便于描述，图2基于图1中示出的分布式数据处理系统的示例性拓扑结构来图示基于异或(xor)的可靠性检测算法。该算法被开发并用于实时流系统storm中。

以下给出该算法的一些关键设计要点：

1.包括根节点的每个节点具有唯一的标识符(id)，根节点的id记为rootnodeid。

2.每个消息(包括根消息或者生成的消息)被指定一个随机生成 的id(例如，为64位，因此通常许多年内在系统中是唯一的)，根消息的id记为rootmsgid，生成的消息的id被记为msgid。

3.此外，每个生成的消息具有嵌入在负载中的元数据，诸如rootnodeid、rootmsgid和其自身的msgid，<rootnodeid,rootmsgid>被用于指示消息来源。

4.对于每个工作节点，例如，一旦接收并处理输入消息a(指代msgid)并且可选地向下游节点发出新消息b和c，则该工作节点将向跟踪任务报告状态，该状态包括如下信息：rootnodeid，rootmsgid，localstatus＝axorbxorc(xor或者⊕表示异或操作)。如果没有新消息生成，则localstatus＝a。

5.跟踪任务针对每个根消息的状态(例如，记为rootstatus)维护一个键-值对：<rootnodeid,rootmsgid>:rootstatus，其中<rootnodeid,rootmsgid>为键，rootstatus为值(例如，为64位)。每当跟踪任务接收到来自节点的状态报告，其将通过输入的<rootnodeid,rootmsgid>来对键进行查找，然后将输入的localstatus与相应的rootstatus进行异或操作以得到新的rootstatus值。

6.重复上述4-5。最终在设定的超时时间段内，跟踪任务中的rootstatus值将为零；非零值意味着发生了故障。

如图2所示，跟踪任务针对根消息a的状态维护一个键-值对：<0,a>:rootstatus。例如，rootstatus的初始值可以设为rootmsgid，即a；或者如图2所示，当根消息a进入节点0时，可以附加地向跟踪任务报告一条状态信息<0,a>:a。图2示出了工作节点1-8向跟踪任务报告的localstatus的值，其中在节点8处，当处理消息i、j、k和l时，节点8可以依次向跟踪任务报告四次状态信息(其中localstatus分别为i、j、k和l)；或者如图2所示，可选地可以将四条状态信息合并为一条状态信息进行发送(其中localstatus为ixorjxorkxorl)。最终，跟踪任务通过将收到的状态消息中对应于<0,a>的localstatus值进行异或，得出对应于<0,a>的rootstatus值为零。

基于异或(xor)的可靠性检测算法的核心思想是以下公式：axoraxorbxorbxor…＝0，其中a、b等为msgid并且是成对的。因此，在理想情况下，每个消息将被示为恰好是成对的，即发送一次接收一次，只要在不超时的情况下接收的顺序无关紧要。如果某个消息被丢失、某个节点崩溃或者发生超时，则在给定的超时时间段内将不会收到相应的状态报告，其必将导致相应的rootstatus不为零。

然而，尽管相对于上述的第一种方法，基于异或(xor)的可靠性检测算法具有规则简单和能够忽略中间复杂逻辑的优点，但是这种方法仍有明显的不足。不足之处在于其仍然产生大量的额外网络流量，因为对于每个输入消息每个节点将通过网络发送一定大小的状态报告；并且该算法对于大型拓扑结构无法很好地扩展，因为更多的节点以及更多进入的消息会导致更多的内部网络流量。不足之处还在于每次状态报告的发出会消耗额外的存储器和cpu资源；此外由于在每个节点处的存储器拷贝所带来的延迟，当成千上万个节点以流水线运行时，汇集的延迟可能达到对于实时流系统而言相当大的毫秒级。此外，该算法使用64位随机数作为msgid并假定其是唯一的，使得当axora＝0时意味着特定消息a已经被处理；然而随机数重复的可能性仍然是存在的，当这种情况发生时，相同的msgid可能指代的并非是同一输入消息。本公开的实施例能够克服基于异或(xor)的可靠性检测算法所存在的上述不足。

图3图示了根据本公开的实施例来进行分布式数据处理的示意图。为了便于描述，图3仍然基于图1中示出的分布式数据处理系统的示例性拓扑结构来图示本公开的实施例。

根据本公开的实施例，在根节点处，针对每个从外部进入的根消息分配一个msgid和大的共享计数，其中msgid可以为随机数或者可以一直增加，并且其中大的共享计数可以是针对每个应用可配置的，例如，可以记为int_share，其可以是32位或者高达64位。该共享计数可以被嵌入在消息的负载中并且是元数据的一部分。同时，针对每个rootmsg，在跟踪任务处还可以存在一个键-值映射，“键”可 以与上述基于异或(xor)的可靠性检测算法中的“键”相同，而“值”可以为总的共享计数(例如，为64位，记为totalsharecnt)，该“值”初始地可以被设定为0。例如，该键-值映射可以记为：<rootnodeid,rootmsgid>:totalsharecnt。

例如，如图3所示，在根节点0处针对根消息a分配了共享计数100，即int_share＝100。应当理解，该共享计数值100仅出于示例的目的。跟踪任务针对根消息a的状态维护一个键-值对：<0,a>:totalsharecnt。

根据本公开的实施例，给定具有共享计数的输入消息，当在节点处生成新消息时，输入的共享计数将被分解并且被分配给每个新消息(例如，分配的新共享计数仍可以作为消息的负载而嵌入，记为sharecnt)。例如，新消息的格式可以是：[rootnodeid,rootmsgid,sharecnt],原始消息数据。共享计数的分配策略可以是针对每个节点可配置的，诸如可以基于下游节点的个数平均地分配给每个新消息或者可以利用每个下游节点的权重来向每个新消息分配新共享计数。

例如，如图3所示，在节点0处生成新消息b和c时，可以将输入的共享计数100平均分配给新消息b和c，即b和c的共享计数分别为100/2＝50。根节点0可以将附接有相应共享计数的新消息b和c分别下发给工作节点1和2。工作节点1和2可以继续将接收到的共享计数进行分解并分配给生成的新消息，然后将附接有相应共享计数的新消息下发给各自的下游节点，直到附接有共享计数的消息到达叶节点8和9。

根据本公开的实施例，中间工作节点不需要通过网络向跟踪任务报告状态，而由根节点和叶节点负责向跟踪任务报告状态。例如，报告的状态信息的格式可以是：rootnodeid,rootmsgid,opcode,sharecnt；其中sharecnt指代该叶节点针对该rootmsgid接收到的共享计数，并且其中opcode是指示跟踪任务如何处理附接的sharecnt的操作码。例如，opcode可以用一个比特来表示，其中0可以指示附接的sharecnt将从跟踪任务处的totalsharecnt中被减除，而1可 以指示附接的sharecnt将被添加至跟踪任务处的totalsharecnt。跟踪任务可以根据接收到的操作码(opcode)来将相应的totalsharecnt增加或者减少sharecnt。在超时时间段内，totalsharecnt应当为零；零意味着所有生成的消息都被成功处理，而非零值意味着发生了故障。

例如，如图3所示，根节点0可以向跟踪任务报告如下状态信息：0，a，1，100(在图3中为了简化省略了rootnodeid)。叶节点9可以向跟踪任务报告如下状态信息：0，a，0，16。叶节点8可以依次向跟踪任务报告四条状态信息：0，a，0，25；0，a，0，25；0，a，0，17以及0，a，0，17。备选地或者附加地，叶节点8还可以将接收到的共享计数汇总，然后向跟踪任务报告一条状态信息：0，a，0，84(其中84＝25+25+17+17)。跟踪任务可以根据接收到的操作码来将相应的totalsharecnt增加或者减少sharecnt，即对应于<0,a>的totalsharecnt为0(初始值)+100–84–16＝0，表示所有生成的消息都被成功处理。

图4图示了根据本公开的另一实施例来进行分布式数据处理的示意图。为了便于描述，图4仍然基于图1中示出的分布式数据处理系统的示例性拓扑结构来图示本公开的另一实施例。

如以上关于图3描述的，通常，init_share默认为32位，其足以支持多达40亿以上的节点。然而，取决于拓扑结构的大小、形状和共享计数的分配策略，中间节点可能没有足够的共享计数来进行分解。根据本公开的实施例，在这种情况下，当在节点处生成新消息时，输入的共享计数可以被增加，并且利用增加后的总共享计数来向每个新消息分配新共享计数。例如，该节点可以增加足够的共享计数直到达到init_share。附加地或者备选地，增加共享计数的节点可以向跟踪任务发送状态信息以指示其增加了多少共享计数。

如图4所示，在根节点0处可以针对根消息a分配了共享计数100，即int_share＝100。根节点0可以向跟踪任务报告如下状态信息：0，a，1，100(在图4中为了简化省略了rootnodeid)。在根节点0处生成新消息b和c时，可以将输入的共享计数100分配给 新消息b和c，使得b和c的共享计数分别为98和2。根节点0可以将附接有相应共享计数的新消息b和c分别下发给工作节点1和2。工作节点1和2可以继续将接收到的共享计数进行分解并分配给生成的新消息。工作节点2需要将接收到的共享计数分配给节点5、6和7，由于节点2接收到的共享计数为2，其不够向三个节点进行分配(假设，不考虑小数的情况)。因此，工作节点2可以增加共享计数98，即增加后的总共享计数为2+98＝100。然后，工作节点可以将增加后的总共享计数100分配给生成的新消息f、g和h，其各自的新共享计数分别为33、33和34。同时，节点2可以向跟踪任务报告如下状态信息：0，a，1，98。接着，重复上述分解共享计数和下发新消息的步骤，直到附接有共享计数的消息到达叶节点8和9。到达叶节点9的消息m所附接的共享计数为34，因此叶节点9可以向跟踪任务报告如下状态信息：0，a，0，34。到达叶节点8的消息i、j、k和l的共享计数分别为49、49、33和33，叶节点8可以依次向跟踪任务报告四条状态信息(即0，a，0，49；0，a，0，49；0，a，0，33以及0，a，0，33)，或者叶节点8可以将接收到的共享计数汇总，然后向跟踪任务报告一条状态信息(即，0，a，0，164，其中164＝49+49+33+33)。跟踪任务可以根据接收到的操作码来将相应的totalsharecnt增加或者减少相应的sharecnt。例如，在对应于<0,a>的totalsharecnt的初始值被设定为0的情况下，最终的totalsharecnt为0+100+98–164–34＝0，表示所有生成的消息都被成功处理。

从图3和图4所示的示例可以看出，本公开的实施例可以根据分布式存储系统的拓扑结构大小来配置初始的共享计数和在每个节点处的共享计数分配策略，例如，针对较小的拓扑结构可以分配4字节(甚至2字节)的共享计数，从而尽可能减小其所需要的存储空间，同时也尽可能减少对其处理时所消耗的cpu资源。共享计数可以被嵌入在消息的负载中，并且随着消息向下游节点传递，因此不存在对拓扑结构的形状的要求，提高针对不同拓扑结构的可扩展性。此外，用于状态报告的网络流量仅发生在根节点和叶节点处，可以大大降低 网络流量上的开销。由于根节点和叶节点的数量较少(通常仅一个根节点和一个或几个叶节点)，随着拓扑结构中存在更多的中间节点，本公开的实施例将相对于现有技术降低更多的网络流量。同时，相对于基于异或的算法，本公开的实施例不使用任何随机数，因此避免了随机数出现重复的风险。

图5图示了根据本公开的实施例的用于在当前节点处的分布式数据处理的方法500的流程图。以下将结合图3和图4来详细描述方法500。例如，方法500可以被实施在图3或图4中所示的节点0-9上。方法500包括步骤s501至s504。

在步骤s501，从一个或多个上游节点接收附接有共享计数的一个或多个输入消息，其中该共享计数被用于确定与一个或多个输入消息相关联的根消息的处理状态。例如，如图3所示，在节点1处，从上游节点(即，根节点0)接收附接有共享计数50的消息b。

回到图5，方法500进行至步骤s502。在步骤s502，处理一个或多个输入消息以生成一个或多个新消息。例如，如图3所示，节点1处理输入消息b，从而生成新消息d和e。

回到图5，方法500进行至步骤s503。在步骤s503，基于接收到的共享计数，向每个新消息分配新共享计数。例如，如图3所示，节点1基于接收到的共享计数为50，向生成的新消息d和e分别分配了共享计数25和25。

回到图5，方法500进行至步骤s504。在步骤s504，向一个或多个下游节点发送附接有相应的新共享计数的一个或多个新消息。例如，如图3所示，节点1向下游节点3和4分别发送附接有共享计数25的消息d和附接有共享计数25的消息e。

至此，方法500结束。

根据本公开的实施例，当当前节点为根节点时，步骤s501可以包括：接收从外部进入的根消息；以及为根消息分配预定的共享计数。例如，如图3所示，根节点1从外部消息队列接收根消息a，并且为根消息a分别预定的共享计数100。

根据本公开的实施例，当当前节点为根节点时，响应于接收到从外部进入的根消息，向跟踪任务报告第一状态信息，第一状态信息包括根消息的标识符、预定的共享计数以及第一操作码，其中第一操作码用于向跟踪任务指示预定的共享计数要被添加。例如，如图3所示，根节点1向跟踪任务报告状态信息，该状态信息包括根消息的标识符(即a)、预定的共享计数(即100)以及操作码(即1)，该操作码指示预定的共享计数(即100)要被添加到跟踪任务处对应于<0,a>的totalsharecnt。

根据本公开的实施例，当当前节点为叶节点时，响应于从一个或多个上游节点接收到附接有共享计数的一个或多个输入消息，向跟踪任务报告第二状态信息，该第二状态信息包括根消息的标识符、叶节点接收到的共享计数以及第二操作码，其中第二操作码用于向跟踪任务指示共享计数要被减除。例如，如图3所示，叶节点9向跟踪任务报告状态信息，该状态信息包括根消息的标识符(即a)、接收到的共享计数(即16)以及操作码(即0)，该操作码指示接收到的共享计数(即16)要从跟踪任务处对应于<0,a>的totalsharecnt中减除。

根据本公开的实施例，步骤s503可以包括基于在当前节点处配置的分配策略，向每个新消息分配新共享计数。所述分配策略包括以下的至少一种：基于一个或多个下游节点的个数，将共享计数之和平均分配给每个新消息；以及利用每个下游节点的权重来向每个新消息分配新共享计数。例如，如图3所示，在节点0处生成新消息b和c时，将输入的共享计数100平均分配给新消息b和c，即b和c的共享计数分别为100/2＝50。

根据本公开的实施例，步骤s502还可以包括向共享计数添加附加的共享计数，以利用添加后的总共享计数向每个新消息分配新共享计数。例如，如图4所示，节点2需要将接收到的共享计数分配给节点5、6和7，由于节点2接收到的共享计数为2，其不够向三个节点进行分配(假设，不考虑小数的情况)。因此，工作节点2可以增加共享计数98，即增加后的总共享计数为2+98＝100。然后，工作节点 可以将增加后的总共享计数100分配给生成的新消息f、g和h，其各自的新共享计数分别为33、33和34。

根据本公开的实施例，方法500还包括响应于向共享计数添加附加的共享计数，向跟踪任务报告第三状态信息，该第三状态信息包括根消息的标识符、附加的共享计数以及第三操作码，其中第三操作码用于向所述跟踪任务指示附加的共享计数要被添加。例如，如图4所示，节点2向跟踪任务报告状态信息，该状态信息包括根消息的标识符(即a)、附加的共享计数(即98)以及操作码，该操作码指示附加的共享计数(即98)要被添加到跟踪任务处对应于<0,a>的totalsharecnt。

图6图示了根据本公开的实施例的用于分布式数据处理的方法600的流程图。以下将结合图3和图4来详细描述方法600。例如，方法600可以被实施在图3或图4中所示的跟踪任务中。方法600包括步骤s601至s604。

在步骤s601，从根节点和叶节点接收与根消息相关联的状态信息。根据本公开的实施例，从根节点和叶节点接收与根消息相关联的状态信息包括从根节点接收第一状态信息，其中第一状态信息包括根消息的标识符、为根消息分配的预定的共享计数以及第一操作码；以及从叶节点接收第二状态信息，其中第二状态信息包括根消息的标识符、叶节点接收到的共享计数以及第二操作码。例如，如图3所示，跟踪任务从根节点0以及叶节点8和9接收与根消息a相关联的状态信息。其中，跟踪任务从根节点0接收到的状态信息包括根消息的标识符(即a)、为根消息分配的预定的共享计数(即100)以及操作码(即1)；从叶节点8接收到的状态信息包括根消息的标识符(即a)、接收到的共享计数(即84)以及操作码(即0)；从叶节点9接收到的状态信息包括根消息的标识符(即a)、接收到的共享计数(即16)以及操作码(即0)。

回到图6，方法600进行至步骤s602。在步骤s602，基于从状态信息中提取的操作码，对包括在状态信息中的共享计数进行处理， 以确定对应于根消息的总共享计数。根据本公开的实施例，基于从状态信息中提取的操作码，对包括在状态信息中的共享计数进行处理，以确定对应于根消息的总共享计数包括：基于第一操作码，向总共享计数添加为根消息分配的预定的共享计数；以及基于第二操作码，从总共享计数中减除叶节点接收到的共享计数。例如，如图3所示，跟踪任务从根节点0接收到的状态信息包括根消息的标识符(即a)、为根消息分配的预定的共享计数(即100)以及操作码(即1)；从叶节点8接收到的状态信息包括根消息的标识符(即a)、接收到的共享计数(即84)以及操作码(即0)；从叶节点9接收到的状态信息包括根消息的标识符(即a)、接收到的共享计数(即16)以及操作码(即0)。因此，跟踪任务可以根据接收到的操作码来将相应的totalsharecnt增加或者减少相应的sharecnt。例如，在对应于<0,a>的totalsharecnt的初始值被设定为0的情况下，最终的totalsharecnt为0+100–84–16＝0。

回到图6，方法600进行至步骤s603。在步骤s603，基于总共享计数，确定根消息的处理状态。例如，根据本公开的实施例，与根消息相对应的总共享计数的初始值可以被设定为零，并且基于总共享计数，确定根消息的处理状态可以包括：响应于总共享计数为零，确定根消息被成功处理；以及响应于总共享计数不为零，确定在根消息的处理中发生故障。如图3所示，对应于<0,a>的totalsharecnt为0+100–84–16＝0，表示所有生成的消息都被成功处理。

至此，方法600结束。

根据本公开的实施例，方法600还可以包括从添加附加共享计数的节点接收第三状态信息，其中第三状态信息包括根消息的标识符、附加共享计数以及第三操作码；并且基于从状态信息中提取的操作码，对包括在状态信息中的共享计数进行处理，以确定对应于根消息的总共享计数还可以包括基于第三操作码，向总共享计数添加附加共享计数。例如，如图4所示，工作节点2增加了共享计数98，然后向跟踪任务报告状态信息，该状态信息包括根消息的标识符(即a)、附加 共享计数(即98)以及操作码(即1)。跟踪任务根据从节点2接收到的操作码1，将相应的totalsharecnt增加98。

出于清楚的目的，在图5和图6中没有示出方法500和600的某些可选步骤。然而，应当理解，上文参考图3-4所描述的各个特征同样适用于方法500和600。

图7图示了根据本公开的实施例的用于在当前节点处的分布式数据处理的设备700的框图。设备700包括消息接收装置701，被配置为从一个或多个上游节点接收附接有共享计数的一个或多个输入消息，其中所述共享计数被用于确定与所述一个或多个输入消息相关联的根消息的处理状态；消息处理装置702，被配置为处理所述一个或多个输入消息以生成一个或多个新消息；共享计数分配装置703，被配置为基于接收到的所述共享计数，向每个新消息分配新共享计数；以及消息发送装置704，被配置为向一个或多个下游节点发送附接有相应的新共享计数的所述一个或多个新消息。

根据本公开的实施例，当所述当前节点为根节点时，消息接收装置701被配置为：接收从外部进入的根消息；以及为所述根消息分配预定的共享计数。

根据本公开的实施例，设备700还包括：第一报告装置，被配置为响应于接收到从外部进入的所述根消息，向跟踪任务报告第一状态信息。所述第一状态信息包括所述根消息的标识符、所述预定的共享计数以及第一操作码，其中所述第一操作码用于向所述跟踪任务指示所述预定的共享计数要被添加。

根据本公开的实施例，设备700还包括：第二报告装置，被配置为当所述当前节点为叶节点时，响应于从所述一个或多个上游节点接收到附接有所述共享计数的所述一个或多个输入消息，向跟踪任务报告第二状态信息。所述第二状态信息包括根消息的标识符、所述叶节点接收到的所述共享计数以及第二操作码，其中所述第二操作码用于向所述跟踪任务指示所述共享计数要被减除。

根据本公开的实施例，共享计数分配装置703被配置为：基于在 所述当前节点处配置的分配策略，向每个新消息分配新共享计数。所述分配策略包括以下的至少一种：基于所述一个或多个下游节点的个数，将所述共享计数平均分配给每个新消息；以及利用每个下游节点的权重来向每个新消息分配新共享计数。

根据本公开的实施例，共享计数分配装置703被配置为：向所述共享计数添加附加的共享计数，以利用添加后的总共享计数向每个新消息分配新共享计数。

根据本公开的实施例，设备700还包括：第三报告装置，被配置为响应于向所述共享计数添加所述附加的共享计数，向跟踪任务报告第三状态信息。所述第三状态信息包括根消息的标识符、所述附加的共享计数以及第三操作码，其中所述第三操作码用于向所述跟踪任务指示所述附加的共享计数要被添加。

图8图示了根据本公开的实施例的用于分布式数据处理的设备800的框图。设备800包括：第一信息接收装置801，被配置为从根节点和叶节点接收与根消息相关联的状态信息；共享计数处理装置802，被配置为基于从所述状态信息中提取的操作码，对包括在所述状态信息中的共享计数进行处理，以确定对应于所述根消息的总共享计数；以及状态确定装置803，被配置为基于所述总共享计数，确定所述根消息的处理状态。

根据本公开的实施例，第一信息接收装置801被配置为：从所述根节点接收第一状态信息，其中所述第一状态信息包括所述根消息的标识符、为所述根消息分配的预定的共享计数以及第一操作码；以及从所述叶节点接收第二状态信息，其中所述第二状态信息包括所述根消息的标识符、所述叶节点接收到的共享计数以及第二操作码。

根据本公开的实施例，共享计数处理装置802被配置为：基于所述第一操作码，向所述总共享计数添加为所述根消息分配的所述预定的共享计数；以及基于所述第二操作码，从所述总共享计数中减除所述叶节点接收到的所述共享计数。

根据本公开的实施例，与所述根消息相对应的所述总共享计数的 初始值被设定为零，并且状态确定装置803被配置为：响应于所述总共享计数为零，确定所述根消息被成功处理；以及响应于所述总共享计数不为零，确定在所述根消息的处理中发生故障。

根据本公开的实施例，设备800还包括：第二信息接收装置，被配置为从添加附加共享计数的节点接收第三状态信息，其中所述第三状态信息包括所述根消息的标识符、所述附加共享计数以及第三操作码。

根据本公开的实施例，共享计数处理装置802被配置为：基于所述第三操作码，向所述总共享计数添加所述附加共享计数。

出于清楚的目的，在图7和图8中没有示出装置700和800的某些可选模块。然而，应当理解，上文参考本公开的方法所描述的各个特征同样适用于装置700和800。而且，装置700和800中的各个模块可以是硬件模块，也可以是软件模块。例如，在某些实施例中，装置700和800可以部分或者全部利用软件和/或固件来实现，例如被实现为包含在计算机可读介质上的计算机程序产品。备选地或附加地，装置700和800可以部分或者全部基于硬件来实现，例如被实现为集成电路(ic)、专用集成电路(asic)、片上系统(soc)、现场可编程门阵列(fpga)等。本公开的范围在此方面不受限制。

下面参考图9，其图示了适于实现本公开的示例实施例的计算机系统900的框图。如图9所示，计算机系统900包括中央处理单元(cpu)901，其可以根据存储在只读存储器(rom)902中的程序或者从存储部分908加载到随机访问存储器(ram)903中的程序而执行各种适当的动作和处理。在ram903中，还存储有装置700和/或装置800操作所需的各种程序和数据。cpu901、rom902以及ram903通过总线904彼此相连。输入/输出(i/o)接口905也连接至总线904。

以下部件连接至i/o接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如 因特网的网络执行通信处理。驱动器910也根据需要连接至i/o接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本公开的实施例，参考图5描述的方法500和/或参考图6描述的方法600可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，所述计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，所述计算机可执行指令在被执行时使得计算机执行方法500和/或600中的任意步骤。

综上所述，根据本公开的实施例，提供了一种用于分布式数据处理的方法和设备。与现有技术相比，根据本公开的实施例的用于分布式数据处理的方法和设备，能够有效降低网络流量上的开销以及所消耗的cpu和存储器资源，并且针对不同分布式数据处理系统的拓扑结构具有可扩展性。

一般而言，本公开的各种示例实施例可以在硬件或专用电路、软件、逻辑，或其任何组合中实施。某些方面可以在硬件中实施，而其他方面可以在可以由控制器、微处理器或其他计算设备执行的固件或软件中实施。当本公开的实施例的各方面被图示或描述为框图、流程图或使用某些其他图形表示时，将理解此处描述的方框、装置、系统、技术或方法可以作为非限制性的示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备，或其某些组合中实施。

而且，流程图中的各框可以被看作是方法步骤，和/或计算机程序代码的操作生成的操作，和/或理解为执行相关功能的多个耦合的逻辑电路元件。例如，本公开的实施例包括计算机程序产品，该计算机程序产品包括有形地实现在机器可读介质上的计算机程序，该计算机程序包含被配置为实现上文描述方法的程序代码。

在公开的上下文内，机器可读介质可以是包含或存储用于或有关于指令执行系统、装置或设备的程序的任何有形介质。机器可读介质 可以是机器可读信号介质或机器可读存储介质。机器可读介质可以包括但不限于电子的、磁的、光学的、电磁的、红外的或半导体系统、装置或设备，或其任意合适的组合。机器可读存储介质的更详细示例包括带有一根或多根导线的电气连接、便携式计算机磁盘、硬盘、随机存储存取器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或闪存)、光存储设备、磁存储设备，或其任意合适的组合。

用于实现本公开的方法的计算机程序代码可以用一种或多种编程语言编写。这些计算机程序代码可以提供给通用计算机、专用计算机或其他可编程的数据处理装置的处理器，使得程序代码在被计算机或其他可编程的数据处理装置执行的时候，引起在流程图和/或框图中规定的功能/操作被实施。程序代码可以完全在计算机上、部分在计算机上、作为独立的软件包、部分在计算机上且部分在远程计算机上或完全在远程计算机或服务器上执行。

另外，尽管操作以特定顺序被描绘，但这并不应该理解为要求此类操作以示出的特定顺序或以相继顺序完成，或者执行所有图示的操作以获取期望结果。在某些情况下，多任务或并行处理会是有益的。同样地，尽管上述讨论包含了某些特定的实施细节，但这并不应解释为限制任何发明或权利要求的范围，而应解释为对可以针对特定发明的特定实施例的描述。本说明书中在分开的实施例的上下文中描述的某些特征也可以整合实施在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以分离地在多个实施例或在任意合适的子组合中实施。

针对前述本公开的示例实施例的各种修改、改变将在连同附图查看前述描述时对相关技术领域的技术人员变得明显。任何及所有修改将仍落入非限制的和本公开的示例实施例范围。此外，前述说明书和附图存在启发的益处，涉及本公开的这些实施例的技术领域的技术人员将会想到此处阐明的本公开的其他实施例。

将会理解，本公开的实施例不限于公开的特定实施例，并且修改 和其他实施例都应包含于所附的权利要求范围内。尽管此处使用了特定的术语，但是它们仅在通用和描述的意义上使用，而并不用于限制目的。