业务的树结构处理方法及装置与流程

1.本技术实施例涉及计算机技术，尤其涉及一种业务的树结构处理方法及装置。


背景技术：

2.树结构是一种非常重要的数据结构，在一些业务场景下，通过树结构可以简单有效的实现计算或者决策。
3.目前，在相关技术中，在针对某个业务场景构建树结构之后，如果说业务场景中的一些业务逻辑发生了变化，那么就需要针对树结构中的相应节点进行更新。同时，出于历史数据回溯计算的需要，以及树节点之间相互依赖的特性，目前的处理方式通常是新建一个树结构，在新建的树结构中进行相应的节点更新。
4.然而，因为新的树结构和旧的树结构被同时保存，随着业务需求的频繁变化，就会导致需要维护的树结构的节点数量急剧增加，进而导致需要维护的节点数量较多。


技术实现要素：

5.本技术实施例提供一种业务的树结构处理方法及装置，以克服需要维护的节点数量较多的问题。
6.第一方面，本技术实施例提供一种业务的树结构处理方法，包括：
7.获取业务调整指令，所述业务调整指令用于指示对目标业务的调整操作；
8.获取所述目标业务对应的第一树结构，其中，所述第一树结构中包括多个原始节点，所述原始节点与所述目标业务中的操作环节相对应；
9.在所述多个原始节点中确定所述调整操作所对应的第一节点；
10.根据所述业务调整指令，生成所述第一节点所对应的更新节点，所述更新节点以及所述多个原始节点中除所述第一节点之外剩余的第二节点，组成第二树结构，所述第二节点为所述第一树结构和所述第二树结构所复用的节点；
11.确定所述更新节点的节点信息，所述节点信息用于指示所述更新节点的版本和所述更新节点的依赖关系。
12.第二方面，本技术实施例提供一种业务的树结构处理装置，包括：
13.获取模块，用于获取业务调整指令，所述业务调整指令用于指示对目标业务的调整操作；
14.所述获取模块，还用于获取所述目标业务对应的第一树结构，其中，所述第一树结构中包括多个原始节点，所述原始节点与所述目标业务中的操作环节相对应；
15.确定模块，用于在所述多个原始节点中确定所述调整操作所对应的第一节点；
16.处理模块，用于根据所述业务调整指令，生成所述第一节点所对应的更新节点，所述更新节点以及所述多个原始节点中除所述第一节点之外剩余的第二节点，组成第二树结构，所述第二节点为所述第一树结构和所述第二树结构所复用的节点；
17.所述处理模块还用于，确定所述更新节点的节点信息，所述节点信息用于指示所
述更新节点的版本和所述更新节点的依赖关系。
18.第三方面，本技术实施例提供一种业务的树结构处理设备，包括：
19.存储器，用于存储程序；
20.处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
21.第四方面，本技术实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
22.第五方面，本技术实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上第一方面以及第一方面各种可能的设计中任一所述的方法。
23.本技术实施例提供一种业务的树结构处理方法及装置，该方法包括：获取业务调整指令，业务调整指令用于指示对目标业务的调整操作。获取目标业务对应的第一树结构，其中，第一树结构中包括多个原始节点，原始节点与目标业务中的操作环节相对应。在多个原始节点中确定调整操作所对应的第一节点。根据业务调整指令，生成第一节点所对应的更新节点，更新节点以及多个原始节点中除第一节点之外剩余的第二节点，组成第二树结构，第二节点为第一树结构和第二树结构所复用的节点。确定更新节点的节点信息，节点信息用于指示更新节点的版本和更新节点的依赖关系。在需要进行业务调整的时候，根据业务调整指令在第一树结构中确定需要调整的第一节点，之后根据业务调整指令，仅针对需要调整的第一节点生成对应的更新节点。然后根据更新节点和未调整的第二节点，组成第二树结构，并且确定更新节点的节点信息，就可以有效的实现对第二树结构的维护，因此本技术的技术方案可以实现基于业务调整对相应的树结构进行更新，同时又可以有效的减少需要维护的节点数量。
附图说明
24.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
25.图1为本技术实施例提供的树结构的结构示意图；
26.图2为本技术实施例提供的一种调整树结构的实现示意图；
27.图3为本技术实施例提供的业务的树结构处理方法的流程图；
28.图4为本技术实施例提供的业务的树结构处理方法的流程图二；
29.图5为本技术实施例提供的树结构调整的实现示意图；
30.图6为本技术实施例提供的处理树结构的界面示意图；
31.图7为本技术实施例提供的业务的树结构处理方法的流程图三；
32.图8为本技术实施例提供的业务信息查询的界面示意图；
33.图9为本技术实施例提供的确定目标树结构的实现示意图；
34.图10为本技术实施例提供的业务的树结构处理装置的结构示意图；
35.图11为本技术实施例提供的业务的树结构处理设备的硬件结构示意图。
具体实施方式
36.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.为了更好的理解本技术的技术方案，下面对本技术所涉及的相关技术进行进一步的详细介绍。
38.树结构是一种非常重要的数据结构，在一些应用场景下，树结构可以简单有效的实现计算或者决策。
39.比如说在销售定价或者计算薪资等场景中，例如数据工程师可以根据指标的含义(即业务逻辑关系)将一个业务指标拆解为多个逻辑独立的子指标，然后子指标按照依赖关系和层级结构可以构建出一棵树结构，此处的树结构也可以理解为规则树。
40.此处首先对指标的一些分类进行说明，其中，原子指标是指使用原始数据且没有任何限定条件加工的指标。衍生指标是指在原子指标的加工逻辑之上添加限定条件产生的指标。复合指标是指使用原值指标或衍生指标经过加、减、乘、除等运算得到的指标。
41.其中，树结构具有简化计算以及计算过程可视化等优点。可以理解的是，树结构中的上层指标需要维护和相邻的下一层子指标的关系，上层指标的计算依赖于下层指标的计算，例如可以为树结构传入必要的参数，就可以从叶子指标沿着指标依赖关系逐层向上计算，直至计算出树根所指代的指标的值。
42.下面比如说以计算薪资这个场景为例，结合图1对上述介绍的内容进行理解，图1为本技术实施例提供的树结构的结构示意图。
43.如图1所示，图1中示出了一个树结构，在这个树结构中包括7个节点。其中，节点e对应的指标是月度总业绩，f对应的指标是月度拉新业绩。
44.以及，d节点是e节点和f节点的上层节点，d节点和e节点以及f节点之间存在依赖关系，其中d节点对应的指标计算是依赖于下层节点的指标计算的，在图1的示例中，d对应的指标计算和e节点、f节点之间的指标计算的关系是，d＝e*10％ f*5％。
45.以及，图1中的c节点对应的指标是迟到次数。a节点是c节点和d节点的上层节点，a节点和c节点以及d节点之间存在依赖关系，其中a节点对应的指标计算是依赖于下层节点的指标计算的，在图1的示例中，a对应的指标计算和c节点、d节点之间的指标计算的关系是，a＝d*5％-c*100。
46.以及，图1中的b节点对应的指标是语言津贴。r节点是a节点和b节点的上层节点，r节点和a节点以及b节点之间存在依赖关系，其中r节点对应的指标计算是依赖于下层节点的指标计算的，在图1的示例中，r对应的指标计算和a节点、b节点之间的指标计算的关系是，r＝a b。比如说r指标对应的就是最终计算得到的薪资。
47.那么在计算薪资的时候，只要针对某个具体的员工，获取其月度总业绩、月度拉新业绩、迟到次数、语言津贴，并将这些数据传入到树结构中，就可以计算得到这个员工的薪资了。
48.上述图1示意性的给出了薪资计算场景下的一个树结构。在实际实现过程中，树结构的具体实现，以及树结构中的各个节点所代表的含义，以及树结构中各个节点之间的关
系，均可以根据实际需求进行选择和设置，本实施例对此不做限制。以及树结构的具体应用场景同样可以根据实际需求进行扩展，比如说还可以应用在一些决策场景等等，本实施例对应用场景的具体实现也不做特殊限定。
49.在针对某个业务场景构建规则树之后，如果说这个业务场景中的业务逻辑发生了变化，那么相应的树结构就需要进行调整。
50.其中，树结构的调整主要可以分为两类，一类是指标内调整，一类是指标间调整。
51.其中，指标内调整通常和计算逻辑变化关系较大，包括指标某变量的系数大小调整、构成指标的变量间(加减乘除)运算关系调整。比如说上述图1中的示例中，节点a对应的指标计算是a＝d*5％-c*100。例如可以对这个计算规则中的系数进行调整，比如说调整成a＝d*10％-c*100。或者说还可以针对这个计算规则中的运算关系进行调整，比如说调整成a＝d*10％ c*100。
52.以及指标间调整通常和业务逻辑变化关系更大，例如某些情况下，下层子指标可能全部被替换为完全不同的新指标。比如说上述图1中的示例中，节点c对应的指标含义是迟到次数，如果说将节点c的指标含义替换为单位时间加班费。
53.可以理解的是，随着业务的发展，树结构中的节点所对应的计算逻辑和业务逻辑可能经常被调整，出于历史数据回溯计算的需要，目前通常采用的调整方式是新建一个全新的树结构，在全新的树结构中对节点的计算逻辑进行调整，并且针对旧的树结构和新的树结构都进行保存和维护。
54.比如说可以结合图2进行理解目前调整树结构的实现，图2为本技术实施例提供的一种调整树结构的实现示意图。
55.如图2所示，树结构201假设是原始的树结构，也就是上述图1中所示意的树结构。
56.假设针对树结构201中的a节点的计算逻辑进行调整，将节点a对应的指标计算调整为a＝d*10％-c*100。以及因为节点r是依赖节点a的，因此针对节点r也要进行相应的调整。
57.那么也就可以得到图2中的树结构202中，相较于树结构201，节点a被调整为节点a`，节点r被调整为节点r`。
58.上述介绍的是一次业务调整的过程，假设在这次业务调整之后，又需要进行下一次的业务调整，那么就是在树结构202的基础上继续进行调整。
59.假设是针对树结构202中的d节点的计算逻辑进行调整，将节点d对应的指标计算调整为d＝(e f)*10％。以及因为节点a`是依赖节点d的，同时节点r`是依赖节点a`的，因此针对节点r`、节点a`也要进行相应的调整。
60.那么也就可以得到图2中的树结构203中，相较于树结构202，节点d被调整为节点d`，节点a`被调整为节点a``，节点r`被调整为节点r``。
61.基于上述图2的示例，其实际上是进行了两次简单的业务调整，在这两次简单的业务调整之后，就已经得到了三个树结构。并且这三个树结构中的节点数量的总数已经达到了21个。
62.比如说上述介绍的树结构201是某个员工在9月份的工资计算树结构，然后树结构202是某个员工在10月份的工资计算树结构，然后树结构203是某个员工在11月份的工资计算树结构。那么比如说在11月份的时候，需要再回溯计算一下这个员工在9月份的工资，那
么就需要调用树结构201。因此出于历史数据回溯计算的需要，现有技术中通常是对每一个版本的树结构都进行保存，并且针对每一个版本的树结构中的节点都进行维护。
63.但是基于上述介绍可以确定的是，上述仅仅是针对一个示例性的简单的树结构中的某两个节点进行了两次业务调整，就导致树结构以及需要维护的节点数量成倍的增加，那么在实际实现过程中，如果按照上述的实现方式，就会导致树结构以及指标数量的翻倍增长，对于一棵复杂的树结构可能包含大量业务指标，那么指标数量的翻倍增长就会造成维护复杂度和成本的急剧增加。
64.基于上述介绍可以确定的是，在指标计算逻辑快速变化的情况下，目前的研究重点就需要从如何计算指标，向如何更好地管理和维护指标转变。因此，本技术提供了一种在业务逻辑频繁变化情况下，仍然能够低成本计算、维护、管理指标的方法。
65.本技术的技术构思如下：尽管业务调整需要对相应的子节点进行更新，但是实际上每次业务调整通常只会影响到小范围的子指标，因此可以充分利用这一特点，复用未发生变化的节点，从而有效的控制新旧树结构的总指标的数量，以降低维护树结构的复杂程度。
66.在上述介绍内容的基础上，下面结合具体的实施例对本技术提供的业务的树结构处理方法进行介绍。需要说明的是，本技术各实施例的执行主体可以是服务器、处理器、芯片等具备数据处理功能的设备，本实施例对具体的执行主体的实现方式不做限制，其可以根据实际需求进行选择和设置。
67.下面首先结合图3进行介绍，图3为本技术实施例提供的业务的树结构处理方法的流程图。
68.如图3所示，该方法包括：
69.s301、获取业务调整指令，业务调整指令用于指示对目标业务的调整操作。
70.在本实施例中，可以获取业务调整指令，其中业务调整指令比如说可以是用户输入的。在一种可能的实现方式中，业务调整指令用于指示对目标业务的调整操作。其中目标业务比如说是薪资计算的业务，再比如说可以是成本计算的业务，本实施例对此不做限制。
71.以及，目标业务的调整操作例如可以是针对目标业务的业务逻辑进行调整，例如在薪资计算的业务中，调整计算指标的含义，或者调整计算指标的计算逻辑等等。在实际实现过程中，业务调整指令的具体指示情况可以根据实际需求进行选择和设置。
72.s302、获取目标业务对应的第一树结构，其中，第一树结构中包括多个原始节点，原始节点与目标业务中的操作环节相对应。
73.本实施例中介绍的是根据业务调整指令所指示的调整操作对树结构进行调整的实现，而不同的业务对应不同的树结构，因此需要首先获取目标业务所对应的第一树结构。
74.其中，在第一树结构中包括多个节点，本实施例中将第一树结构中的节点称为原始节点，其中每个原始节点都可以理解为与目标业务中的操作环节相对应，各个原始节点的操作环节就共同构成了目标业务的处理逻辑。
75.以及在一种可能的实现方式中，每个原始节点都可以分别对应各自的业务信息。其中业务信息比如说可以是节点所对应的指标含义，例如上述介绍的示例中，c节点对应的指标是迟到次数，那么c节点对应的业务信息就可以是迟到次数。
76.或者说业务信息还可以是节点对应于下层指标的计算逻辑，例如上述介绍的示例
中，r节点对应于下层指标计算逻辑就是a节点的指标和b节点的指标之和。同时上述示例中的r节点也对应有自己的指标含义，也就是薪资。
77.在实际实现过程中，每个节点的业务信息的具体实现可以根据实际的业务场景和业务需求进行设计，本实施例对此不做限制。
78.s303、在多个原始节点中确定调整操作所对应的第一节点。
79.可以理解的是，本实施例中的业务调整指令用于指示对目标业务进行调整，而目标业务的具体操作环节就体现在第一树结构中的各个元素节点中，那么业务调整指令所指示的调整操作，反映在第一树结构中，就可以理解为业务调整指令指示对某些原始节点的业务信息进行调整，然而树结构中的节点是存在依赖关系的，因此针对某些原始节点的业务信息进行了调整，相应的依赖这些原始节点的上层节点的业务信息也需要进行相应的调整，也就是说业务调整指令所指示的调整操作是会涉及一定的调整范围的。
80.因此本实施例中就可以在多个原始节点中确定调整操作所对应的第一节点，也就是说业务调整指令所涉及到的、需要调整业务信息的节点。
81.s304、根据业务调整指令，生成第一节点所对应的更新节点，更新节点以及多个原始节点中除第一节点之外剩余的第二节点，组成第二树结构，第二节点为第一树结构和第二树结构所复用的节点。
82.在确定第一节点之后，其中第一节点的业务信息都需要响应于业务调整指令进行相应的调整，因此本实施例中可以根据业务调整指令，生成第一节点所对应的更新节点。
83.其中，更新节点的业务信息，就是进行了业务调整指令所对应的调整之后的节点。
84.在针对需要调整的第一节点，生成对应的更新节点之后，还可以在多个元素节点中确定除第一节点之外剩余的第二节点，其中更新节点和第二节点就可以组成第二树结构。可以理解的是，第二树结构就是在第一树结构的基础上调整后的树结构。
85.因为第二节点是未发生变化的节点，因此可以在第一树结构和第二树结构之间复用。这样的话，针对未发生变化的节点，就无需再额外的进行创建和维护，从而可以有效的减少需要维护的节点数量，进而减少需要维护的节点数量。
86.s305、确定更新节点的节点信息，节点信息用于指示更新节点的版本和更新节点的依赖关系。
87.在确定更新节点之后，更新节点和第二节点就已经组成了第二树结构，同时因为只有更新节点是新增的节点，因此本实施例中可以生成更新节点的节点信息。
88.在一种可能的实现方式中，在确定更新节点的节点信息之后，比如说还可以将更新节点的节点信息存储至数据库，以实现对更新节点和第二树结构的有效维护。
89.因为第二节点是原本就存在的节点，因此其节点信息已经存储在数据库中了，那么在将更新节点的节点信息存储在数据库中之后，实际上就实现了对第二树结构的存储，本实施例中的节点信息可以指示更新节点的版本和更新节点的依赖关系。
90.本技术实施例提供的业务的树结构处理方法，包括：获取业务调整指令，业务调整指令用于指示对目标业务的调整操作。获取目标业务对应的第一树结构，其中，第一树结构中包括多个原始节点，原始节点与目标业务中的操作环节相对应。在多个原始节点中确定调整操作所对应的第一节点。根据业务调整指令，生成第一节点所对应的更新节点，更新节点以及多个原始节点中除第一节点之外剩余的第二节点，组成第二树结构，第二节点为第
一树结构和第二树结构所复用的节点。确定更新节点的节点信息，并将更新节点的节点信息存储至数据库，节点信息用于指示更新节点的版本和更新节点的依赖关系。在需要进行业务调整的时候，根据业务调整指令在第一树结构中确定需要调整的第一节点，之后根据业务调整指令，仅针对需要调整的第一节点生成对应的更新节点。然后根据更新节点和未调整的第二节点，组成第二树结构，并且确定更新节点的节点信息，就可以有效的实现对第二树结构的维护，因此本技术的技术方案可以实现基于业务调整对相应的树结构进行更新，同时又可以有效的减少需要维护的节点数量。
91.在上述实施例的基础上，下面结合图4至图5对本技术提供的业务的树结构处理方法进行进一步的详细介绍，图4为本技术实施例提供的业务的树结构处理方法的流程图二，图5为本技术实施例提供的树结构调整的实现示意图。
92.如图4所示，该方法包括：
93.s401、获取业务调整指令，业务调整指令用于指示对目标业务的调整操作。
94.其中，s401的实现方式与上述介绍的s301的实现方式类似。
95.s402、获取目标业务对应的第一树结构，其中，第一树结构中包括多个原始节点，原始节点与目标业务中的操作环节相对应。
96.其中，s402的实现方式与上述介绍的s302的实现方式类似。
97.下面结合图5以一个具体的示例进行说明，假设目标业务所对应的第一树结构是图5中的501中所示出的，由节点r、节点a、节点b、节点c、节点d、节点e以及节点f构成的第一树结构。那么这些节点也就可以理解为本实施例中的原始节点，其中各个原始节点所各自对应的业务信息，比如说可以参照图1中的示例进行理解。
98.s403、根据业务调整指令，在多个原始节点中确定第三节点。
99.在本实施例中，业务调整指令用于指示对第一树结构中的第三节点所对应的业务信息进行调整。
100.其中针对第三节点的业务信息的调整，比如说可以是对第三节点的指标含义进行调整，或者还可以是针对第三节点相对于下层节点的计算逻辑进行调整。也就是说此处介绍的调整可以存在上述介绍的指标内调整和指标间调整的不同情况。
101.以及需要说明的是，第三节点是业务调整指令所直接指示的需要进行业务调整的节点。
102.比如说可以结合图5的示例进行理解，假设图5中的节点e所代表的指标含义是月度总业绩。然后业务调整指令用于指示将节点e所代表的指标含义调整为月度总单数。那么就可以确定节点e就是本实施例中的第三节点。
103.s404、在第一树结构中，获取依赖于第三节点的依赖节点。
104.可以理解的是，如果针对第三节点进行调整的话，那么依赖于第三节点的节点也都需要进行相应的调整。因此本实施例中还可以进一步的在第一树结构中，获取与第三节点存在依赖关系的依赖节点。
105.比如说在图5的示例中，第三节点是节点e，其中第一结构中节点e的上层节点包括节点r、节点a、节点b、节点c、节点d这5个节点。之后需要在这5个节点中获取与节点e存在依赖关系的节点。
106.参照图5可以确定的是，节点d是直接依赖节点c的，节点a和节点r是间接依赖节点
c的，因此可以确定与节点e存在依赖关系的依赖节点就包括节点r、节点a、节点d，因此可以确定依赖节点包括节点r、节点a以及节点d。
107.s406、将第三节点以及依赖节点，确定为第一节点。
108.本实施例中的第三节点是业务调整指令所直接指示调整的节点，而依赖节点是依赖于第三节点所需要调整的节点，因此可以将第三节点和依赖于第三节点的依赖节点，都确定为第一节点。本实施例中的第一节点也就是需要进行业务信息调整的节点。
109.s407、创建第三节点对应的更新节点，并根据业务调整指令对第三节点对应的更新节点的业务信息进行设置。
110.下面对第三节点的业务信息调整和依赖节点的业务信息调整分别进行说明。在本实施例中，第三节点的业务信息调整是业务调整指令所直接指示的，因此本实施例中可以首先创建第三节点所对应的更新节点，并且根据业务调整指令，对第三节点所对应的更新节点的业务信息进行设置。
111.可以理解的是，如果第三节点是叶子节点的话，那么业务调整指令所指示的对第三节点的业务信息的调整，比如说可以是调整第三节点的指标含义。比如说在图5的示例中，业务调整指令用于指示将节点e的指标含义调整为月度总单数。
112.则参照图5，可以生成节点e所对应的更新节点，也就是图5所示的节点e`。然后可以将节点e`的业务信息(指标含义)设置为月度总单数，从而完成业务调整指令的指示。
113.或者，在另一种可能的情况下，如果第三节点不是叶子节点，那么针对第三节点的调整比如说可以是调整第三节点相对于下层节点的计算逻辑。那么同样可以生成第三节点所对应的更新节点，然后针对第三节点所对应的更新节点，将其计算逻辑设置为业务调整指令所指示的计算逻辑。
114.或者，还有一种可能的情况下，如果第三节点不是叶子节点，以及针对第三节点的调整比如说可以是调整第三节点和下层节点的依赖关系，比如说删除和某些下层节点的依赖关系和/或新增和某些下层节点的依赖关系。那么同样可以生成第三节点所对应的更新节点，然后针对第三节点所对应的更新节点，将其依赖关系和/或计算逻辑设置为业务调整指令所指示的情况。
115.因此可以理解的是，针对业务指示信息所直接指示的第三节点的业务信息的调整，可以直接新建一个相应的节点，然后根据业务指示信息的具体指示情况，对新建节点的业务信息进行相应的设置。其中业务指示信息的具体指示内容可以根据实际需求进行选择和设置。
116.s408、创建依赖节点所对应的更新节点。
117.以及本实施例中还需要针对依赖节点生成对应的更新节点。比如说在图5的示例中，上述介绍了确定的依赖节点包括节点r、节点a、节点d。
118.参照图5，针对节点d就创建了对应的更新节点d`,针对节点a就创建了对应的更新节点a`,针对节点r就创建了对应的更新节点r`。
119.s407、获取依赖节点原始的依赖关系，并将原始的依赖关系中的第三节点替换为第三节点对应的更新节点，得到更新后的依赖关系。
120.可以理解的是，本实施例中的依赖节点原本是依赖于第三节点的，而本实施例中针对第三节点生成了对应的更新节点，因此在生成依赖节点所对应的更新节点之后，依赖
节点所对应的更新节点的依赖关系也要发生相应的调整。
121.在一种可能的实现方式中，例如可以获取依赖节点原始的依赖关系，然后将原始的依赖关系中的第三节点替换为第三节点所对应的更新节点，从而得到更新后的依赖关系。
122.比如说可以结合图5的示例进行说明。以依赖节点d为例，节点d原始的依赖关系是，节点d依赖于节点e和节点f，因为当前节点e生成了对应的更新节点e`，那么相应的就需要将“依赖于节点e和节点f”的这个依赖关系，修改为“依赖于节点e`和节点f”，从而得到更新后的依赖关系。
123.s409、获取依赖节点原始的计算逻辑，并将原始的计算逻辑中的第三节点替换为第三节点对应的更新节点，得到更新后的计算逻辑。
124.以及需要说明的是，针对原始节点中的任一个非叶子节点，其业务信息都是其根据其所依赖的子节点的业务信息计算得到的，那也就是说针对每一个非叶子节点，其都存在对应于依赖的子节点的计算逻辑。可以理解的是，非叶子节点就算除叶子节点之外的节点。
125.可以理解的是，本实施例中的依赖节点原本是和第三节点之间存在一定的计算逻辑，而本实施例中针对第三节点生成了对应的更新节点，因此在生成依赖节点所对应的更新节点之后，依赖节点所对应的更新节点的计算逻辑也要发生相应的调整。
126.在一种可能的实现方式中，例如可以获取依赖节点原始的计算逻辑，然后将原始的计算逻辑中的第三节点替换为第三节点所对应的更新节点，从而得到更新后的计算逻辑。
127.比如说可以结合图5的示例进行说明。以依赖节点d为例，假设节点d原始的计算逻辑：d＝e*10％ f*5％，因为当前节点e生成了对应的更新节点e`，那么相应的就需要将“d＝e*10％ f*5％”的这个计算逻辑，修改为“d＝e`*10％ f*5％”，从而得到更新后的计算逻辑。
128.s410、将更新后的依赖关系和更新后的计算逻辑，对依赖节点所对应的更新节点的业务信息进行设置。
129.在得到更新后的依赖关系之后，就可以将更新后的依赖关系设置为依赖节点所对应的更新节点的依赖关系。以及，在得到更新后的计算逻辑之后，就可以将更新后的计算逻辑设置为依赖节点所对应的更新节点的计算逻辑，从而完成对依赖节点所对应的更新节点的业务信息的设置。
130.比如说在图5的示例中，同样是针对依赖节点d，基于上述介绍可以确定的是，针对依赖节点d生成了对应的更新节点d`，同时基于上述介绍还可以确定，我们得到了更新后的依赖关系“依赖于节点e`和节点f”，以及更新后的计算逻辑“d＝e`*10％ f*5％”。因此可以确定，节点d`的依赖关系是依赖于节点e`和节点f，以及节点d`的计算逻辑是d`＝e`*10％ f*5％。其中d`＝e`*10％ f*5％比如说就可以理解为节点d`的业务信息，其中依赖关系也可以理解为业务信息。
131.上述介绍的是针对依赖节点d确定对应的更新节点d`的实现方式，针对依赖节点a确定对应的更新节点a`的实现方式，以及针对依赖节点r确定对应的更新节点r`的实现方式类似，此处不再赘述。
132.在图5的示例中，第一节点对应的更新节点实际上就包括节点r`、节点a`、节点d`、节点e`。以及，在第一树结构中未发生变化的第二节点就包括节点f、节点c和节点b。
133.可以理解的是，上述过程中确定了节点r`、节点a`、节点d`、节点e`的业务信息，以及节点f、节点c和节点b的业务信息未发生变化，那么节点r`、节点a`、节点d`、节点e`、节点f和节点c和节点b就可以组成调整后的第二树结构，其中各个节点之间的依赖关系，每个节点的指标含义，每个节点相对于下层节点的计算逻辑，也都进行了相应的确定，因此就可以确定得到需要的第二树结构，基于第二树结构进行相应的计算或者决策，就可以满足实际业务场景下的计算需求和决策需求。
134.s411、根据第一节点的版本标识，生成第一节点所对应的更新节点的版本标识。
135.可以理解的是，每一个更新节点实际上都是在其对应的第一节点的基础上进行调整所得到的，因此本实施例中的更新节点可以理解为第一节点的下一个版本的节点，为了便于访问各个版本的节点，针对每次业务调整过程中所生成的更新节点，都会记录其节点信息。
136.在一种可能的实现方式中，比如是可以在第一版本的版本标识的基础上进行递增，从而生成第一节点所对应的更新节点的版本标识。比如说第一节点的版本标识是v1，那么第一节点所对应的更新节点的版本标识比如说可以是v2。
137.在实际实现过程中，更新节点所对应的版本标识的具体确定方式，可以根据实际需求进行选择和设置，只要保证针对每次调整后的更新节点，可以和调整之前的原始节点进行区分即可。
138.s412、针对任一个更新节点，获取更新节点对应的依赖信息，依赖信息包括：更新节点所依赖的子节点、更新节点所依赖的子节点的版本标识、以及更新节点的其所依赖的子节点之间的计算逻辑。
139.本实施例中在生成第二树结构之后，还需要针对第二树结构进行维护，可以理解的是，第二树结构中的第二节点是原本在第一树结构中，并且没有发生变化的节点，因此第二节点的相关信息已经进行了存储和维护了。那么本实施例中只需要再对更新节点的节点信息进行存储和维护，就可以实现对第二树结构的维护了。
140.以及本实施例中维护各个节点，是为了在需要的时候确定相应的树结构。因此本实施例中还需要针对各个更新节点，确定更新节点所对应的依赖信息。其中，依赖信息中可以包括更新节点所依赖的子节点，以及子节点可能也存在不同的版本，因此依赖信息中还可以包括更新节点所依赖的子节点的版本标识。以及在确定树结构的时候，还需要确定更新节点所对应的计算逻辑，因此在依赖信息中还可以包括更新节点的和其所依赖的子节点之间的计算逻辑。
141.或者，如果更新节点是叶子节点，也就是说其不存在依赖的子节点的情况下，比如说可以确定该更新节点的依赖信息为空。在这种情况下比如说可以存储该更新节点的指标含义。
142.s413、将更新节点的版本标识以及更新节点的依赖信息，确定为更新节点的节点信息。
143.在确定更新节点的版本标识以及更新节点的依赖信息之后，比如说可以将更新节点的版本标识和更新节点的依赖信息，确定为更新节点的节点信息。
144.以及，在节点信息中所包括的具体内容还可以根据实际需求进行选择和扩展，比如说节点信息中还可以包括更新节点的生成时刻、更新节点的提交时刻等等，本实施例对此不做限制。
145.s414、将更新节点的节点信息存储至数据库，节点信息用于指示更新节点的版本和依赖关系。
146.在确定更新节点的节点信息之后，可以将更新节点的节点信息存储到数据库。可以理解的是，本实施例中对新生成的节点进行相应的数据存储和维护，实际上就实现了对第二树结构的存储和维护。
147.以及还可以结合图5中的502对当前实施例中介绍的过程进行一个完整的说明。可以理解的是，上述介绍的过程中比如说确定了由节点r`、节点a`、节点d`、节点e`、节点f、节点c和节点b所组成的第二树结构。
148.之后如果再需要针对节点r`、节点a`、节点d`、节点e`、节点f、节点c和节点b所组成的树结构进行调整的话，那么就可以将这个树结构再作为新的第一树结构进行相应的调整。
149.比如说参照502中的示例，假设业务调整指令指示针对节点d`的业务信息进行调整，那么可以将节点d`确定为第一节点，以及将依赖于节点d`的节点a`和节点r`也确定为第一节点。
150.然后针对节点d`、节点a`和节点r`确定相应的更新节点，得到图5中所示的节点d``的节点a``和节点r``。以及针对这三个更新节点，会按照上述介绍的实现方式确定相应的依赖关系、计算逻辑等等，从而可以得到图5所示的由节点r``、节点a``、节点d``、节点e`、节点f、节点c和节点b所组成的第二树结构。之后再针对节点r``、节点a``、节点d``的节点信息进行确定和存储，从而可以实现对新生成的树结构和节点的维护，其实现方式与上述介绍的类似。
151.可以理解的是，图5中的501和502示意的同样是针对一个树结构的两次业务调整，但是在图5的示意中，两次业务调整完之后的节点数量只有14个，相较于上述介绍的实现方式，有效的减少了需要维护的节点数量。
152.本技术实施例提供的业务的树结构处理方法，在获取到业务调整指令之后，将原始节点中业务调整指令所直接指示的第三节点，以及依赖于第三节点的依赖节点，都确定为需要调整的第一节点，从而保证可以完整有效的在多个原始节点中确定业务调整指令所涉及的节点。之后针对需要调整的各个第一节点，都创建相应的更新节点。并且针对其中的第三节点所对应的更新节点，是根据业务调整指令的指示，对第三节点所对应的更新节点的业务信息进行设置。以及针对依赖节点所对应的更新节点，是根据依赖节点的原始依赖关系和原始计算逻辑，对依赖节点所对应的更新节点的业务信息进行设置，从而可以保证针对第一节点所对应的更新节点，可以实现业务调整指令所指示的调整。之后再针对更新节点确定其版本标识和依赖关系，然后将版本标识和依赖关系进行关联存储，从而可以实现对更新节点的节点信息的有效维护。其中，更新节点和第一树结构中未发生调整的第二节点可以构成第二树结构，然而第二节点的相关信息之前已经进行过存储和维护了，因此本实施例中仅仅对更新节点的节点信息进行存储和维护，就可以有效的实现对树结构的调整，同时又可以有效的减少需要维护的节点数量。
153.在上述介绍内容的基础上，下面结合图6对树结构编辑的操作界面进行一个示例性的介绍。图6为本技术实施例提供的处理树结构的界面示意图。
154.如图6所示，在操作界面上可以提供有树结构的各层结构，比如说图6中的“销售”这个业务指标，当前示意的版本标识是v2，其例如可以对应上述介绍的树结构中的r`。
155.再比如说图6中的“销售”这个业务指标，下面一层的业务指标包括底薪和语言津贴。其中，底薪在图6中示意的版本标识是v2，其例如可以对应上述介绍的树结构中的a`。以及，语言津贴在图6中示意的版本标识是v1，其例如可以对应上述介绍的树结构中的b。
156.再比如说图6中的“底薪”这个业务指标，下面一层的业务指标包括业绩和迟到次数。其中，业绩在图6中示意的版本标识是v2，其例如可以对应上述介绍的树结构中的d`。以及，迟到次数在图6中示意的版本标识是v1，其例如可以对应上述介绍的树结构中的c。
157.再比如说图6中的“业绩”这个业务指标，下面一层的业务指标包括月度总业绩和月度拉新业绩。其中，月度总业绩在图6中示意的版本标识是v2，其例如可以对应上述介绍的树结构中的e`。以及，月度拉新业绩在图6中示意的版本标识是v1，其例如可以对应上述介绍的树结构中的f。
158.那么基于当前图6中的示意和上述图5中示意的树结构，可以理解的是，图6中所展示的树结构实际上就是上述图5中介绍的由节点r`、节点a`、节点d`、节点e`、节点f、节点c和节点b所组成的树结构。
159.在这个树结构的基础上，用户可以进一步的对树结构进行调整，比如说针对每一个节点，本实施例在界面中都提供了添加、详情、编辑、删除的控件。那么用户可以操作相应的控件，从而实现对树结构中的相应节点的调整，具体的调整方式可以参照上述实施例的介绍。
160.在调整完成之后得到对应的更新节点，然后将更新节点再保存在数据库中，就可以实现对调整后的树结构的存储。
161.以及参照图6还可以确定的是，本实施例中还可以记录调整树结构的人员以及调整树结构的时间。在一种可能的实现方式中，用户在调整树结构的时候，可以先对树结构进行锁定，以防止同时有多人对同一个树结构进行调整。然后再树结构的调整过程中可以进行一些试算，其中试算也就是说基于调整过程中的树结构试着算一下相应的计算逻辑，如果试算之后认为当前树结构的调整已经可以提交了，则将树结构进行提交并保存。
162.其中提交树结构的时候，实际上也就是针对树结构中的更新节点进行保存的过程。在一种可能的实现方式中，参照图6，本实施例中还可以记录用户修改树结构的时候，以及比如说还可以保存树结构的镜像。此处的树结构的镜像可以仅仅是各个节点的节点信息，而非完整的树结构。
163.在当前用户调整完成之后，就可以针对树结构进行解锁，允许其余用户再进行相应的编辑。
164.在上述实施例的基础上，可以理解的是，本实施例中的树结构是用于进行某些业务场景下的计算和决策的，那么在实际使用过程中，比如说可以根据用户提交的业务查询请求，进行相应的计算和决策，以输出用户所需要查询的业务信息。
165.下面结合图7至图8对基于业务的树结构处理查询请求的实现方式进行介绍，图7为本技术实施例提供的业务的树结构处理方法的流程图三，图8为本技术实施例提供的业
务信息查询的界面示意图，图9为本技术实施例提供的确定目标树结构的实现示意图。
166.如图7所示，该方法包括：
167.s701、获取业务查询请求，业务查询请求中包括待查询的业务信息所对应的目标节点以及目标节点的目标版本标识。
168.在本实施例中，用户可以向系统提交查询请求，在查询请求中包括待查询的业务信息所对应的目标节点。
169.可以理解的是，因为本实施例中的树结构随着业务的推进在发生着变化，相应的，也就是说一个指标可能存在多个不同的版本，因此用户在进行业务信息查询的时候，通常需要指定查询的是哪个版本的业务信息。
170.比如说可以结合图8进行理解，如图8所示，假设当前用户已经查询到了底薪是10000，然后基于图8中的界面还可以知道，底薪这个指标是由业绩指标和迟到次数指标所共同确定的。
171.同时，因为业绩这个指标还有下一层的节点，因此针对业绩这个指标，在图形用户界面上还提供有“明细”控件，当用户点击明细控件的时候，就可以生成对业绩这个指标的业务查询请求，同时在业务查询请求中还包括这个指标所对应的目标版本标识。
172.以及还需要说明的是，因为迟到次数所对应的节点已经是一个叶子节点了，也就是说是没有下一层可以查询的东西，因此在图形用户界面上不会显示明细控件。
173.同时还需要说明的是，针对计算薪资的这个场景下，用户可以查询当月的工资，也可以查询之前的月份的工资。以及在每一个月份中，该月份所具体对应的树结构中的各个节点具体是哪个版本，比如说在数据库中有相应的存储。
174.例如针对11月份的薪资计算的树结构，其比如说可以是节点r`、节点a`、节点d`、节点e`、节点f、节点c和节点b所组成的树结构，那么相应各个节点的节点信息就比如说可以是图7中所示意的情况。
175.再比如说针对9月份的薪资计算的树结构，是节点r、节点a、节点d、节点e、节点f、节点c和节点b所组成的树结构，那么业绩这个指标所对应的版本比如可以是v1，以及月度拉新业绩这个指标所对应的版本也可以是v1。
176.在实际的查询过程中，用户可以选择相应的查询月份，然后系统例如可以基于用户所需要的查询月份，确定待查询的业务信息所对应的版本标识，从而得到业务查询请求中所包括的目标版本标识。
177.在实际实现过程中，具体的查询信息中所包括的待查询的业务信息以及目标版本标识可以根据实际的查询需求进行确定，本实施例对此不做限制。
178.s702、根据待查询的业务信息以及目标版本标识，确定目标节点。
179.可以理解的是，因为本实施例中在进行树结构的调整的时候，是针对各个指标所对应的节点对应的生成了新版本。比如说在上述介绍的示例中，针对业绩这个指标，其存在d、d`、d``这三个版本的节点。其中节点d的版本标识比如说可以是v1，节点d`的版本标识比如说可以是v2，节点d``的版本标识比如说可以是v3。
180.那么假设说待查询的业务信息是“业绩”，以及目标版本标识是v2，那么相应的就可以确定目标节点是节点d`。
181.s703、获取目标节点的依赖信息。
182.因为本实施例中存储了各个目标节点的节点信息，以及节点信息中包括版本标识和依赖信息。因此在确定目标节点之后，就可以获取目标节点的依赖信息了。
183.比如说延续上述的介绍，当前确定了目标节点是节点d`,则可以获取目标节点a`的依赖信息。
184.s704、将目标节点作为根节点，根据目标节点的依赖信息，获取目标节点所依赖的各层子节点以及目标节点和其所依赖的各层子节点之间的计算规则。
185.s705、根据目标节点所依赖的各层子节点以及目标节点和其所依赖的各层子节点之间的计算逻辑，确定目标树结构。
186.下面对s704和ss705同时进行介绍。本实施例中的目标节点就是用户当前所需要查询的节点，因此可以将目标节点作为根节点，根据目标节点的依赖信息，获取目标节点所依赖的各层子节点以及目标节点和其所依赖的各层子节点之间的计算逻辑。
187.比如说可以结合图9进行理解，可以理解的是，因为本实施例中维护的是各个节点的版本标识和依赖关系，因此实际上新增的节点会将树结构不断的扩充，从而得到一颗三维立体的树结构，比如说图9中的901所示的树结构，其在最开始的树结构的基础上经过两次业务调整，就得到了901所示的树结构的情况。
188.之后，用户可以根据实际需求在这个树结构中确定自己所需要的部分树结构。比如说当前的示例中，用户待查询的目标节点是d`，那么可以获取节点d`的依赖关系。
189.参照图9，节点d`依赖于节点e`和节点f，以及还可以获取节点d`和节点e`、节点f之间的计算逻辑，从而得到图9中的901所示的目标树结构。
190.再比如说用户待查询的目标节点是a`，那么可以获取节点a`的依赖关系。
191.参照图9，节点a`依赖于节点c和节点d`，以及还可以获取节点a`和节点c、节点d`之间的计算逻辑。同时，节点d`又依赖于节点e`和节点f，以及还可以获取节点d`和节点e`、节点f之间的计算逻辑，从而得到由节点a`、节点c、节点d`、节点e`和节点f所构成的目标树结构。
192.s706、根据目标树结构，确定业务查询请求所对应的查询结果。
193.在确定目标树结构之后，就可以根据根据目标树结构，确定业务查询请求所对应的查询结果。当前示例中的业务查询请求是用于请求查询构成业绩这个指标的明细，则可以根据目标树结构，确定构成节点d`的下层子节点的业务信息，并进行相应的展示，比如说可以参照图8中所展示的月度总业绩和月度拉新业绩的明细信息。
194.当前示例的情况是用户需要查询某一个指标的明细的情况，在另一种应用场景下，比如说用户需要查询的是某一个指标的具体数值。比如说用户要查询自己的业绩是多少，那么就可以基于确定的目标树结构，输入相应的参数然后进行计算，从而将计算得到的结果确定为查询结果。
195.本技术实施例提供的业务的树结构处理方法，可以根据用户的查询请求信息，在系统所维护的多个节点中首先查找到查询请求信息所对应的目标节点，之后根据目标节点的依赖信息，确定目标节点所对应的目标树结构，然后基于目标树结构确定相应的查询结果。从而可以保证基于每次针对新增的更新节点进行新增维护，然后针对未发生变化的节点进行复用的实现方式，可以有效的满足用户的业务查询需求。同时，因为本实施例中针对每一个节点都记录有版本标识，而在查询请求信息中通过携带需要查询的业务信息的版本
标识，就可以有效的实现对历史数据的回溯计算和查询，同时又无需每次都维护完整的树结构，因此可以有效的降低树结构维护的复杂性。
196.综上所述，本技术实施例提供的业务的树结构处理方法，通过在树结构中引入节点的版本标识，从而可以将需要独立维护的各个树结构，转换成由携带版本标识的节点所构成的树结构，以尽可能的复用相同版本的节点，达到控制节点数量，降低节点管理的成本和复杂度的目的。以及，通过在树结构中引入节点的版本标识，可以在经常变化的指标之间维护版本的一致性。
197.图10为本技术实施例提供的业务的树结构处理装置的结构示意图。如图10所示，该装置100包括：获取模块1001、确定模块1002以及处理模块1003。
198.获取模块1001，用于获取业务调整指令，所述业务调整指令用于指示对目标业务的调整操作；
199.所述获取模块1001，还用于获取所述目标业务对应的第一树结构，其中，所述第一树结构中包括多个原始节点，所述原始节点与所述目标业务中的操作环节相对应；
200.确定模块1002，用于在所述多个原始节点中确定所述调整操作所对应的第一节点；
201.处理模块1003，用于根据所述业务调整指令，生成所述第一节点所对应的更新节点，所述更新节点以及所述多个原始节点中除所述第一节点之外剩余的第二节点，组成第二树结构，所述第二节点为所述第一树结构和所述第二树结构所复用的节点；
202.所述处理模块1003还用于，确定所述更新节点的节点信息，所述节点信息用于指示所述更新节点的版本和所述更新节点的依赖关系。
203.在一种可能的设计中，所述业务调整指令用于指示对所述第一树结构中的第三节点所对应的业务信息进行调整；
204.所述确定模块1002具体用于：
205.根据所述业务调整指令，在所述多个原始节点中确定所述第三节点；
206.在所述第一树结构中，获取依赖于所述第三节点的依赖节点；
207.将所述第三节点以及所述依赖节点，确定为所述第一节点。
208.在一种可能的设计中，所述处理模块1003具体用于：
209.创建所述第三节点对应的更新节点，并根据所述业务调整指令对所述第三节点对应的更新节点的业务信息进行设置；
210.创建所述依赖节点所对应的更新节点，并根据所述第三节点对应的更新节点，对所述依赖节点所对应的更新节点的业务信息进行设置。
211.在一种可能的设计中，针对所述原始节点中的任一个非叶子节点，所述非叶子节点的业务信息是根据其所依赖的子节点的业务信息计算得到的；
212.所述处理模块1003具体用于：
213.获取所述依赖节点原始的依赖关系，并将所述原始的依赖关系中的所述第三节点替换为所述第三节点对应的更新节点，得到更新后的依赖关系；
214.获取所述依赖节点原始的计算逻辑，并将所述原始的计算逻辑中的所述第三节点替换为所述第三节点对应的更新节点，得到更新后的计算逻辑；
215.根据所述更新后的依赖关系和所述更新后的计算逻辑，对所述依赖节点所对应的
更新节点的业务信息进行设置。
216.在一种可能的设计中，所述处理模块1003具体用于：
217.根据所述第一节点的版本标识，生成所述第一节点所对应的更新节点的版本标识；
218.针对任一个所述更新节点，获取所述更新节点对应的依赖信息，所述依赖信息包括：所述更新节点所依赖的子节点、所述更新节点所依赖的子节点的版本标识、以及所述更新节点的其所依赖的子节点之间的计算逻辑；
219.将所述更新节点的版本标识以及所述更新节点的依赖信息，确定为所述更新节点的节点信息。
220.在一种可能的设计中，所述处理模块1003还用于：
221.获取业务查询请求，所述业务查询请求中包括待查询的业务信息以及目标版本标识；
222.根据所述待查询的业务信息以及所述目标版本标识，确定目标节点；
223.以所述目标节点为根节点，确定所述目标节点所对应的目标树结构；
224.根据所述目标树结构，确定所述业务查询请求所对应的查询结果。
225.在一种可能的设计中，所述处理模块1003具体用于：
226.获取所述目标节点的依赖信息；
227.以所述目标节点为根节点，根据所述目标节点的依赖信息，获取目标树结构。
228.在一种可能的设计中，所述处理模块1003具体用于：
229.将所述目标节点作为根节点，根据所述目标节点的依赖信息，获取所述目标节点所依赖的各层子节点以及所述目标节点和其所依赖的各层子节点之间的计算逻辑；
230.根据所述目标节点所依赖的各层子节点以及所述目标节点和其所依赖的各层子节点之间的计算逻辑，确定所述目标树结构。
231.本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
232.图11为本技术实施例提供的业务的树结构处理设备的硬件结构示意图，如图11所示，本实施例的业务的树结构处理设备110包括：处理器1101以及存储器1102；其中
233.存储器1102，用于存储计算机执行指令；
234.处理器1101，用于执行存储器存储的计算机执行指令，以实现上述实施例中业务的树结构处理方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。
235.可选地，存储器1102既可以是独立的，也可以跟处理器1101集成在一起。
236.当存储器1102独立设置时，该业务的树结构处理设备还包括总线1103，用于连接所述存储器1102和处理器1101。
237.本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上业务的树结构处理设备所执行的业务的树结构处理方法。
238.在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者
可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
239.上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本技术各个实施例所述方法的部分步骤。
240.应理解，上述处理器可以是中央处理单元(英文：central processing unit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，简称：dsp)、专用集成电路(英文：application specific integrated circuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
241.存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，还可以为u盘、移动硬盘、只读存储器、磁盘或光盘等。
242.总线可以是工业标准体系结构(industry standard architecture，isa)总线、外部设备互连(peripheral component，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本技术附图中的总线并不限定仅有一根总线或一种类型的总线。
243.上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
244.本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
245.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。