一种数据恢复方法和装置与流程

1.本发明涉及系统管理技术领域，特别是涉及一种数据恢复方法和装置。


背景技术：

2.在存在多个组件的系统中，常常需要在不关闭系统的情况下，对其中的某一个组件进行升级、重启或下线修整，在此过程中组件中的数据可能被更改，当组件重新上线时，为了保证组件能够正常工作，需要保证组件中的数据与下线时的数据一致，若组件还连接有下游组件时，由于下游组件中的数据需要与组件的数据保持一致，故还需要对下游组件进行数据同步，这一过程统称为数据恢复。
3.当一个组件既有上游组件又有下游组件时，将这样的组件称为中游组件，当中游组件进行数据恢复时，在现有技术中，通常采用的方法如图1所示，在中游组件下线前，将中游组件自身的中游业务数据完整复制到外部存储中，当中游组件重新上线时，从外部存储中读取中游业务数据，并与中游组件上线后从上游组件接收的业务数据进行校核，根据校核结果更新恢复自身的中游业务数据，当自身的中游业务数据恢复结束后，再生成用于下游组件数据同步的目标数据，将目标数据下发给下游组件。
4.在现有技术中，从外部存储恢复数据的过程通常花费的时间较长，并且在校核与生成目标数据的过程中通常需要关闭上游组件的数据下发，即中断上游组件与中游组件间的通信，以防止在系统正常运行过程中，上游组件下发业务数据干扰导致数据恢复错误，在数据恢复后，再建立上游组件与中游组件间的通信，此时系统正常运行过程中的业务数据才得以下发，由于通信的中断，系统整体对外呈现无响应状态。
5.鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。


技术实现要素：

6.本发明要解决的技术问题是组件数据恢复过程中，由于通信的中断，系统整体对外呈现无响应状态。
7.本发明采用如下技术方案：
8.一种数据恢复方法，所述方法包括：在上线时，根据从上游组件接收到的历史业务数据生成目标数据，将目标数据存储到目标缓存中，从目标缓存中依次取出目标数据，将目标数据下发给下游组件，用于下游组件的数据同步；
9.在将目标数据下发给下游组件的过程中，根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中；
10.在将目标数据下发给下游组件完成后，从目标缓存中依次取出增量目标数据，将增量目标数据下发给下游组件，用于下游组件的数据更新。
11.优选的，所述根据从上游组件接收到的历史业务数据生成目标数据，将目标数据存储到目标缓存中，具体包括：
12.接收历史业务数据，根据历史业务数据中的一个或多个业务对象，生成一条或多
条过程数据；
13.若发现新接收到的历史业务数据中的业务对象与曾接收到的历史业务数据中的业务对象相同，则不根据新接收到的历史业务数据生成所述业务对象的过程数据，而是根据新接收到的历史业务数据对曾经生成的所述业务对象的过程数据进行更新；
14.在接收到全部的历史业务数据后，根据过程数据生成目标数据，将目标数据存储到所述目标缓存中。
15.优选的，所述根据过程数据生成目标数据，将目标数据存储到目标缓存中，具体包括：
16.根据过程数据按照所述下游组件所要求的数据形式生成目标数据，按照所述下游组件所要求的目标数据的接收顺序，将目标数据存储到所述目标缓存中。
17.优选的，所述按照所述下游组件所要求的目标数据的接收顺序，将目标数据存储到目标缓存中，具体包括：
18.若所述下游组件所要求的目标数据的接收顺序为按照目标数据的类型先后排序接收，则根据目标数据的类型不同，定义不同的链表，将类型相同的目标数据存储到同一个链表中；
19.根据所述下游组件所要求的目标数据的类型的接收顺序，将各个链表中的节点按顺序要求挂接到所述目标缓存中。
20.优选的，所述根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中，具体包括：
21.根据目标缓存的使用情况，控制增量业务数据的接收速率，根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中。
22.优选的，所述根据目标缓存的使用情况，控制增量业务数据的接收速率，具体包括：
23.若所述目标缓存的数据量大于等于预设第一数据量，则将增量业务数据的接收速率降低为最小接收速率；若所述目标缓存的数据量小于等于预设第二数据量，则将增量业务数据的接收速率恢复为正常接收速率；若所述目标缓存的数据量小于预设第一数据量且大于预设第二数据量，则根据所述目标缓存的数据量的变化趋势控制增量业务数据的接收速率。
24.优选的，所述根据所述目标缓存的数据量的变化趋势控制增量业务数据的接收速率，具体包括：
25.若在预设时间内，所述目标缓存中的数据持续增多，且数据增多的速率始终超过预设最大速率，则将增量业务数据的接收速率降低为最小接收速率；若所述目标缓存中的数据持续增多，数据增多的速率始终未超过预设最小速率，或所述目标缓存中的数据减少或不增多，则将增量业务数据的接收速率恢复为正常接收速率。
26.优选的，所述从目标缓存中依次取出目标数据，将目标数据下发给下游组件，具体包括：
27.依次取出所述目标缓存中的目标数据，将取出的目标数据下发到目标管道中，下游组件从所述目标管道中实时读取目标数据；
28.若所述目标管道中的目标数据的数量超过预设数量，则将从所述目标缓存中取目
标数据的速率降低为最小下发速率；若所述目标管道中的目标数据的数量低于预设最小数量，则将从所述目标缓存中取目标数据的速率恢复为正常下发速率。
29.优选的，所述从目标缓存中依次取出增量目标数据，将增量目标数据下发给下游组件，具体包括：
30.依次从目标缓存中取出增量目标数据，将增量目标数据下发给下游组件，根据目标缓存的使用情况，控制增量业务数据的接收速率。
31.第二方面，本发明还提供了一种数据恢复装置，用于实现第一方面所述的数据恢复方法，所述装置包括：
32.至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行第一方面所述的数据恢复方法。
33.第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的数据恢复方法。
34.本发明通过从上游组件接收历史业务数据，根据历史业务数据进行数据恢复，避免了外部存储的介入，使数据恢复过程更稳定，并通过将系统正常运行过程中下发的增量业务数据滞后处理的方式，避免了数据恢复过程中的通信中断，使系统整体对外依旧保持响应。本发明的优选实现方式还根据目标缓存的使用情况控制增量业务数据的接收情况，起到了在数据恢复过程中均衡系统中各个组件负载的效果，在本发明的优选方法中，还对目标缓存进行了更细致的监测，根据目标缓存中的数据量的变化趋势，预测系统负载失衡的可能性，并提前预防，从而进一步平衡系统负载，本发明的优选方法在数据恢复后，依旧对系统负载平衡进行了监测控制，使系统在正常运行过程中，各个组件的负载保持均衡。
附图说明
35.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
36.图1是本发明提供的一种现有技术中数据恢复方法的示意图；
37.图2是本发明实施例提供的一种数据恢复方法的流程图；
38.图3是本发明实施例提供的一种数据恢复方法的示意图；
39.图4是本发明实施例提供的一种数据恢复方法的流程图；
40.图5是本发明实施例提供的一种数据恢复方法的流程图；
41.图6是本发明实施例提供的一种数据恢复方法的应用场景示意图；
42.图7是本发明实施例提供的一种数据恢复方法的流程图；
43.图8是本发明实施例提供的一种数据恢复方法的应用场景示意图；
44.图9是本发明实施例提供的一种数据恢复方法的示意图；
45.图10是本发明实施例提供的一种数据恢复方法的流程图；
46.图11是本发明实施例提供的一种数据恢复装置的架构示意图。
具体实施方式
47.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
48.在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。
49.此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
50.实施例1:
51.本发明实施例1提供了一种数据恢复方法，如图2所示，所述方法具体包括：
52.在步骤201中，在上线时，根据从上游组件接收到的历史业务数据生成目标数据，将目标数据存储到目标缓存中，从目标缓存中依次取出目标数据，将目标数据下发给下游组件，用于下游组件的数据同步。
53.所述历史业务数据是曾经下发过的能够生成目标数据的业务数据，在上线时，通过将历史业务数据重新下发的方式生成目标数据，实现下游组件的数据同步，所述历史业务数据的数量为一条或多条，其中，一条历史数据可以以一个完整的数据包的形式下发，也可以拆分为多个数据包下发，根据本发明实施例所应用的场景不同，根据一条历史业务数据能够生成一条或多条目标数据，或根据多条历史业务数据生成一条目标数据均是可能的。
54.将上线的组件称为中游组件，中游组件上线后，上游组件将历史业务数据下发给中游组件，中游组件根据历史业务数据生成自身的中游业务数据，所述中游业务数据是正常业务运行过程中存储于中游组件中的数据，使中游组件自身数据恢复到与下线时一致，并根据数据恢复后的中游业务数据生成目标数据。本过程通过与上游组件交互，根据历史业务数据生成自身的中游业务数据和目标数据，使数据恢复的过程无需外部存储的参与。
55.下游组件接收到目标数据，会使用目标数据与自身的数据进行校核，若与自身的数据不同，则用目标数据恢复自身的数据。从目标缓存中依次取出目标数据的速率是由本领域技术人员根据下游组件的处理目标数据的性能分析得出的。
56.在步骤202中，在将目标数据下发给下游组件的过程中，根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中。
57.所述增量业务数据是系统正常运行过程中下发的业务数据，所述根据从上游组件接收到的增量业务数据生成增量目标数据具体为：根据增量业务数据更新中游组件的中游业务数据，根据增量业务数据和中游业务数据生成增量目标数据。
58.由于在生成增量目标数据过程中，与生成用于下游数据同步的目标数据过程同样需要更改中游业务数据，若在生成目标数据的同时处理生成增量目标数据，可能导致中游业务数据被增量业务数据更改，导致生成的目标数据错误，进而导致数据恢复错误，故对增量业务数据进行暂不处理。
59.在目标数据下发的过程中，此时生成目标数据的过程已完成，而将目标数据下发给下游组件的过程中，由于下游组件需要根据目标数据进行数据同步，花费时间较长，在此
过程中，中游组件处理增量业务数据生成增量目标数据，通过此方式，一方面能够在不关闭上游组件的数据下发的情况下，保障数据恢复的正确性，另一方面，通过将生成增量目标数据与下发目标数据同时进行的方式，使中游组件的负载得到充分利用，缩短了增量业务数据等待处理的时间，使系统在恢复数据结束后，能够尽快进入正常运行状态。
60.在步骤203中，在将目标数据下发给下游组件完成后，从目标缓存中依次取出增量目标数据，将增量目标数据下发给下游组件，用于下游组件的数据更新。
61.所述数据更新是指在系统正常运行过程中的根据系统的业务需求更新组件的数据。若在下发目标数据过程中将增量业务数据处理并下发，可能导致下游组件的数据同步过程被干扰，导致数据同步错误，也可能在将增量业务数据处理并下发后，又因数据同步导致数据更改，使增量业务数据并未起到应有的作用，故在目标数据下发完成后，再下发增量目标数据。
62.本发明实施例的场景示意图如图3所示。本发明实施例通过接收上游组件下发的历史业务数据生成中游业务数据和目标数据的方式，一方面防止了数据恢复过程中外部存储的介入，使数据恢复过程更稳定，另一方面，通过将系统正常运行过程中下发的增量业务数据滞后到目标数据生成结束后处理，将增量目标数据的下发滞后到目标数据下发结束后，从而使数据恢复过程不受增量业务数据下发的影响，使组件的数据同步与数据更新过程有序进行，保障数据恢复正常进行，进而使上游组件和下游组件的通信无需中断，使系统在数据恢复过程中仍能保持对外界的响应。
63.在实际使用情况中，所述历史业务数据通常是下线时记录的全部历史业务数据，结合本发明实施例，如图4所示，将进一步融合本实施例中的关联步骤进行相对完整逻辑展示：
64.在步骤200中，在下线时通知所述上游组件，所述上游组件记录此时能够生成目标数据的历史业务数据。
65.所述历史业务数据是由上游组件曾经下发过的能够生成目标数据的业务数据，故可由上游组件自身记录，而不必引入外部存储，在一些情况下，上游组件为管理组件，即本身具有管理功能，用于存储并管理能够生成自身及中游组件和下游组件的数据的数据结构，在这种情况下，上游组件无需为历史业务数据额外开辟一份存储空间，而是仅需记录中游组件下线时上游组件所管理的数据结构的存储位置，并保持该存储结构不变，并将后续系统运行过程中的业务数据存储到其他位置，以此来记录此时能够生成目标数据的历史业务数据，从而起到节省缓存空间的效果。
66.在一些情况下，可能存在有多条历史业务数据所针对的业务对象相同，即可能多条历史业务数据只是对同一个业务对象的同一条信息设置不同的值，由于对下游组件来说，所关注的只是在处理所有历史业务数据后，所设置的业务对象的信息的最终值，而不关注在历史业务数据处理过程中这些值的变化，故无需下发多条目标数据导致下游组件的数据频繁更新，只需下发带有最终值的目标数据，结合本发明实施例，存在以下优选的实施例：
67.接收历史业务数据，根据历史业务数据中的一个或多个业务对象，生成一条或多条过程数据。
68.若发现新接收到的历史业务数据中的业务对象与曾接收到的历史业务数据中的
业务对象相同，则不根据新接收到的历史业务数据生成所述业务对象的过程数据，而是根据新接收到的历史业务数据对曾经生成的所述业务对象的过程数据进行更新。
69.在接收到全部的历史业务数据后，根据过程数据生成目标数据，将目标数据存储到所述目标缓存中。
70.其中，一条历史业务数据中可能包含多个业务对象，或多条历史业务数据用于描述一个业务对象的不同属性的值。即一条历史业务数据可能生成多条过程数据，或多条历史业务数据生成一条过程数据。由于历史业务数据中可能包含多个业务对象，其中可能存在部分业务对象与曾接收到的历史业务数据中的业务对象相同，部分业务对象与曾接收到的历史业务数据中的业务对象不同，此时，只针对相同的业务对象更新过程数据，对不同的业务对象仍需要生成新的过程数据。
71.通过对旧的过程数据的更新，保证针对一个业务对象仅有一个过程数据，在未接收到全部的历史业务数据时，不生成目标数据，即不向下游组件下发数据，避免将未更新结束的值下发到下游组件。在接收到全部的历史业务数据后，再根据过程数据生成目标数据，以保证下游组件所接收到的每一个业务对象的每一个信息的值都是最新的值。
72.本优选实施例能够避免针对相同业务对象的目标数据重复下发，缩减组件重启后数据恢复的时间。
73.还存在下游组件对下发的数据形式及数据的下发顺序有严格要求的情况，此时，本优选的实施例还包括：
74.根据过程数据按照所述下游组件所要求的数据形式生成目标数据，按照所述下游组件所要求的目标数据的接收顺序，将目标数据存储到所述目标缓存中。
75.由于针对一个业务对象生成一个过程数据，但下游组件所需要接收的数据可能并非是针对业务对象的数据，此时，则对过程数据进行加工，使数据形式符合下游组件所要求的数据形式，如：若下游组件所需要接收的数据是针对业务对象下的属性，则将过程数据拆分出属性的值作为目标数据；若下游组件所需要的是针对业务对象的数据，则将过程数据作为目标数据。
76.其中，所述按照下游组件所要求的目标数据的接收顺序，将目标数据存储到目标缓存中，可以划分出一份连续的物理内存作为目标缓存，将目标数据按照一定的字节大小连续存储，也可以使用线性表作为目标缓存，也可以是生成一份指定目标数据的顺序的数据，如将每一个目标数据的地址顺序存储。
77.若所述下游组件所要求的目标数据的接收顺序为按照目标数据的类型先后排序接收，则根据目标数据的类型不同，定义不同的链表，将类型相同的目标数据存储到同一个链表中。
78.根据所述下游组件所要求的目标数据的类型的接收顺序，将各个链表中的节点按顺序要求挂接到所述目标缓存中。
79.每个链表中的节点中存储一个目标数据，所述将各个链表中的节点按顺序要求挂接到所述目标缓存中具体为，从链表头开始遍历链表中的目标数据，将目标数据挂接到目标缓存中，将一个链表中的全部目标数据挂接到目标缓存中后，再挂接下一个链表。
80.本优选的实施例能够适应下游组件对数据的下发形式和下发顺序有严格要求的系统，使目标数据能够按照下游组件要求的顺序和形式下发，满足系统数据恢复的需求。
81.在本实施例中，由于目标数据的下发与增量目标数据的生成这两个过程同时进行，当中游组件所能够承受的负载，即所能够处理的数据量一定的情况下，这两个过程的处理速率必然互相影响，即当中游组件大量处理增量目标数据的生成时，目标数据的下发速率必然减缓，又由于在数据恢复结束前，系统的正常运行会受到影响，故需要优选保证数据恢复能够尽快完成，即需要优先保障目标数据的下发过程，针对此问题，结合本发明实施例，存在以下优选的实现方式：
82.根据目标缓存的使用情况，控制增量业务数据的接收速率，根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中。
83.所述目标缓存的使用情况包括：目标缓存中目标数据所占的缓存大小，目标缓存中增量目标数据所占的缓存大小，目标缓存所能容纳的数据量大小。由于目标缓存通常处于中游组件内部，其所能容纳的数据量与中游组件所能承受的负载，即所能处理的数据量匹配，故目标缓存的使用情况能够在一定程度上代表中游组件的负载情况。通过目标缓存的使用情况，判断目标数据的数量和下发速率，根据目标数据的数量和下发速率，控制增量业务数据的接收速率，从而控制增量目标数据的生成速率，从而达到增量目标数据的生成与目标数据的下发这两个过程的动态平衡，使在保障数据恢复能够尽快完成的前提下，能够根据中游组件的负载量控制生成增量目标数据的速率。
84.所述控制增量业务数据的接收速率的一种实现方式为：通告上游组件，使上游组件控制下发增量业务数据的速率；还存在另一种实现方式为：建立上游组件向中游组件下发增量业务数据的管道，中游组件控制从管道中读取增量业务数据的速率，上游组件则通过管道中增量业务数据的量，控制增量业务数据的下发速率。这两种实现方式均能够使增量业务数据的下发速率得到控制，使上游组件根据中游组件的负载情况控制上游组件的数据向中游组件转移的速率，从而保持上游组件与中游组件间的负载均衡。
85.上述优选的实现方式能够根据目标缓存的使用情况，动态调整增量业务数据的接收速率，从而控制中游组件处理增量目标数据的生成和目标数据的下发这两个过程的动态平衡，同时通过根据中游组件的负载情况控制增量业务数据的下发速率的方式，能够保持上游组件与中游组件间的负载均衡。
86.以上实现方式中为通过目标缓存中目标数据所占的缓存大小、增量目标数据所占的缓存大小以及目标缓存所能容纳的数据量大小来控制增量业务数据的接收速率，当目标缓存过小或增量业务数据的接收速率过快或目标数据的下发速率过慢时，可能导致目标缓存中的数据量突然增多，即中游组件的负载偏大，此时，虽然通过控制增量业务接收速率减少增量目标数据的生成速率，但仍需要经过一段时间的目标数据的下发，才能够使目标缓存的数据量恢复到正常范围内，使中游组件处理增量目标数据的生成和目标数据的下发这两个过程恢复平衡状态，针对此问题，结合本实施例，如图5所示，有以下优选的实现方式：
87.在步骤301中，若所述目标缓存的数据量大于等于预设第一数据量，则将增量业务数据的接收速率降低为最小接收速率；若所述目标缓存的数据量小于等于预设第二数据量，则将增量业务数据的接收速率恢复为正常接收速率；若所述目标缓存的数据量小于预设第一数据量且大于预设第二数据量，则根据所述目标缓存的数据量的变化趋势控制增量业务数据的接收速率。
88.所述预设第一数据量、预设第二数据量、最小接收速率和正常接收速率为本领域
技术人员根据经验和目标缓存所能允许的目标数据的数量分析得出的，其中，最小接收速率小于正常接收速率，预设第一数据量大于等于预设第二数据量，第一数据量小于等于目标缓存所能够允许的最大数据量。
89.在步骤302中，若在预设时间内，所述目标缓存中的数据持续增多，且数据增多的速率始终超过预设最大速率，则将增量业务数据的接收速率降低为最小接收速率；若所述目标缓存中的数据持续增多，数据增多的速率始终未超过预设最小速率，或所述目标缓存中的数据减少或不增多，则将增量业务数据的接收速率恢复为正常接收速率。
90.所述预设时间、预设最大速率和预设最小速率为本领域技术人员根据经验分析得出的，其中，预设最大速率大于等于预设最小速率。
91.当目标缓存中的数据增多时，说明目标数据的下发速率小于增量业务数据的生成速率，当目标缓存中的数据减少或不增多时，说明目标数据的下发速率大于等于增量业务数据的生成速率。若数据增多的速率大于等于预设最大速率的状况持续一段时间后，可能导致目标缓存中的数据量大于预设第一数据量；反之，若数据增多的速率始终小于预设最小速率，或所述目标缓存中的数据减少或不增多的状况持续一段时间，能够将目标数据中的数据量保持在预设第一数据量或预设第一数据量以下。故通过目标缓存中的数据量的变化趋势，能够预测未来一段时间后目标缓存的数据量，根据目标缓存中的数据量的变化趋势控制增量业务数据的接收速率，从而控制增量目标数据的生成速率，在一定程度上预防目标缓存中的数据量超出预设第一数据量，达到预防目标缓存中的数据量超出限度的目的，即根据目标缓存中数据量的变化趋势，判断中游组件中增量目标数据的生成和目标数据的下发的相对速率，根据此相对速率，预测中游组件中可能的负载变化，从而通过控制增量目标数据的生成速率，防止中游组件处理增量目标数据的生成和目标数据的下发这两个过程的动态平衡被打破，使中游组件的负载能够保持稳定，同时，也使中游组件与上游组件间的负载保持稳定平衡。
92.本优选的实现方式能够保持中游组件中的处理增量目标数据的生成和目标数据的下发这两个过程的稳定平衡，也保持了中游组件与上游组件间的负载稳定平衡。
93.在下游组件所能承受的负载有限的情况下，当下发目标数据的速率过快时，下游组件可能来不及处理，针对此情况，结合本发明实施例，有以下实现方式：
94.根据下游组件的负载情况，控制目标数据的下发速率。
95.即中游组件根据下游组件的负载情况，平衡中游组件与下游组件的负载分配。其实现方式有多种，其中的一种实现形式为：下游组件向中游组件通告自身的负载情况，中游组件根据负载情况控制目标数据的下发速率。
96.还存在一种优选的实现方式为：
97.依次取出所述目标缓存中的目标数据，将取出的目标数据下发到目标管道中，下游组件从所述目标管道中实时读取目标数据。
98.若所述目标管道中的目标数据的数量超过预设数量，则将从所述目标缓存中取目标数据的速率降低为最小下发速率；若所述目标管道中的目标数据的数量低于预设最小数量，则将从所述目标缓存中取目标数据的速率恢复为正常下发速率。
99.所述预设数量、最小下发速率和正常下发速率为本领域技术人员根据经验分析得出的，其中，最小下发速率小于正常下发速率。
100.所述将取出的目标数据下发到目标管道中，下游组件从目标管道中实时读取目标数据，具体为：
101.将目标数据依次送入目标管道的一端，下游组件从目标管道的另一端读取目标数据，以达到目标数据先进先出的效果，当下游组件对目标数据的接收顺序有要求时，则按照下游组件所要求的目标数据的接收顺序，将目标数据按照依次送入目标管道的一端。
102.其中，下游组件从目标管道的另一端读取目标数据的速率由下游组件自身处理数据的能力决定的，即由下游组件所能承受的负载决定的。
103.本优选的实施例根据下游组件的负载情况，控制目标数据的下发速率，从而达到平衡中游组件与下游组件间的负载的效果，同时，目标数据的下发过程为从目标缓存中取出目标数据，下发给下游组件，故目标数据的下发速率会直接影响目标缓存中目标数据的数据量大小，以该实现方式结合上述根据目标缓存的使用情况，控制增量业务数据的接收速率的实现方式，能够根据下游组件的负载情况，平衡中游组件与下游组件的负载分配，进而平衡上游组件与中游组件的负载分配，达到系统中上游组件、中游组件、下游组件的负载均衡的效果，从而保障系统在数据恢复过程中的整体负载均衡。
104.在一些情况下，不仅需要保证系统在数据恢复过程中的整体负载均衡，还需要在系统正常运作过程中，保持系统的负载均衡，针对此情况，有以下优选的实现方式：
105.依次从目标缓存中取出增量目标数据，将增量目标数据下发给下游组件，根据目标缓存的使用情况，控制增量业务数据的接收速率。
106.通过控制增量业务数据的接收速率，控制增量目标数据的生成速率，从而控制将增量目标数据下发给下游组件的速率，从而控制上游组件、中游组件、下游组件的负载均衡。
107.在本发明实施例中，所述上游组件、中游组件和下游组件并非指系统中固定位置的组件，而是指这些组件在数据下发过程中具有上下级关系，具体为：在数据下发过程中，中游组件处于上游组件的下级，接收由上游组件下发的数据，下游组件处于中游组件的下级，接收由中游组件下发的数据。而当下游组件之下还存在其他组件接收由下游组件下发的数据时，这些组件并不直接感知中游组件的重启过程，若中游组件重启过程中需要将数据下发给这些组件，则会由下游组件处理下发，下发时不进行增量目标数据与目标数据的区分，即不影响中游组件的重启过程。当上游组件的上级还存在其他组件时，由于数据是从上级发送到下级的，故中游组件的重启过程不对上游组件以上的组件产生影响。即在系统中，凡是位于此上下级关系中的中游组件的数据恢复过程，本发明实施例均可适用。
108.在本发明实施例中，第一、第二等限定性描述，并非是指代特定顺序含义，仅仅是为了让对应限定的对象能够从同类中脱离出来，并且是为了方便描述同类中不同的两个对象或者多个对象方便而加的限定，不应该将其解释出进一步限定意义。
109.实施例2:
110.在实际应用过程中，系统中可能存在多个下游组件。本发明实施例基于实施例1所描述的方法基础上，针对此场景，来阐述本发明特性场景下的实现过程。如图6所示，系统中存在第一组件、第二组件、第三组件、第四组件，其中，第二组件位于第一组件的下级，第三组件与第四组件均位于第二组件的下级。
111.在第二组件重启上线时，如图7所示，有以下实现方式：
112.在步骤401中，第二组件在上线时，根据从第一组件接收到的历史业务数据生成目标数据，将目标数据存储到目标缓存中。
113.在步骤402中，从目标缓存中依次取出目标数据，将取出的目标数据下发到第一目标管道和第二目标管道中，第三组件和第四组件分别从第一目标管道和第二目标管道中实时读取目标数据。
114.在步骤403中，若所述第一目标管道或第二目标管道中目标数据的数量超过预设数量，则将从所述目标缓存中取目标数据的速率降低为最小下发速率；若所述第一目标管道和第二目标管道中的目标数据的数量均低于预设最小数量，则将从所述目标缓存中取目标数据的速率恢复为正常下发速率。
115.在步骤404中，在将目标数据下发给第三组件和第四组件的过程中，根据从上游组件接收到的增量业务数据生成增量目标数据，将增量目标数据存储到目标缓存中。
116.在步骤405中，在将目标数据下发给第三组件和第四组件完成后，从目标缓存中依次取出增量目标数据，将增量目标数据下发给第三组件和第四组件，用于第三组件和第四组件的数据更新。
117.在上述实现方式中，当存在两个下游组件时，根据两个下游组件的负载情况，控制增量业务数据的处理速度，当两个下游组件中的任意一个负载较重时，则减缓增量业务数据的接收速率，从而保证在数据恢复中所有下游组件的负载均衡。当存在两个以上的下游组件时，其实现过程均可通过由上述实现方式加以拓展得到，在此不加以赘述。
118.在本发明实施例中，第一、第二等限定性描述，并非是指代特定顺序含义，仅仅是为了让对应限定的对象能够从同类中脱离出来，并且是为了方便描述同类中不同的两个对象或者多个对象方便而加的限定，不应该将其解释出进一步限定意义。
119.实施例3:
120.本发明基于实施例1所描述的方法基础上，结合具体的应用场景，并借由相关场景下的技术表述来阐述本发明特性场景下的实现过程。如图8所示，为一个l3vpn网络中的一个路由器下的局部功能组件场景，其中，单播路由管理组件501用于管理所有路由信息，是业务依赖管理组件502的上游组件，驱动适配组件503用于驱动管理接口等硬件，是业务依赖管理组件502的下游组件，业务依赖管理组件502用于根据业务依赖管理组件下发的历史业务数据生成驱动适配组件503所需的数据，并下发给驱动适配组件503。
121.业务依赖管理组件502在下线时分别通过三次握手告知单播路由管理组件501和驱动适配组件503，单播路由管理组件501记录此刻管理的路由信息的存储位置，将此刻管理的路由信息作为历史业务数据，当后续接收到路由信息的更改命令时，将更改路由信息的命令作为增量业务数据。
122.业务管理依赖组件502上线时，通过三次握手告知单播路由管理组件501，单播路由管理组件501随即依次下发历史业务数据，业务依赖管理组件502接收到历史业务数据，根据历史业务数据的业务对象实时生成过程数据，如生成第一条过程数据的业务对象为路由a的前缀地址，生成第二条过程数据的业务对象为路由b的下一跳出接口，当后续再接收到历史业务数据所生成的过程数据的业务对象为路由b的下一跳出接口时，则将第二条过程数据根据当前接收到的历史业务数据进行数据同步，以保证只有一个路由b的下一跳出接口的过程数据，且该过程数据的值永远是最新值。
123.由于驱动适配组件503所需要接收的数据同样是根据业务对象分类的，故此处业务依赖管理组件502生成的过程数据能够直接作为目标数据使用，即第一条过程数据即为第一条目标数据，第二条过程数据即为第二条目标数据。驱动适配组件503要求按照不同业务对象的类型顺序下发，即按照先下发前缀地址，再下发下一跳出接口的方式下发目标数据，故将第一条目标数据挂载到用于存储前缀地址类型的过程数据的第一链表中，将第二条目标数据挂载到用于下一跳出接口类型的过程数据的第二链表中，若还存在其他类型的过程数据，则挂载到存储对应类型的过程数据的链表中，如图9所示。
124.在下发历史业务数据结束后，单播路由管理组件501会推送完成下发的消息，此时，如同8所示，业务依赖管理组件502使用目标链表作为目标缓存，遍历所有类型的过程数据的链表，根据驱动适配组件503的接收要求，将第一链表中的目标数据挂载到目标链表中后，再将第二链表中的目标数据挂载到目标链表中，当所有的目标数据都挂载完成后，在最后一个目标数据的链尾添加结束标志。
125.单播路由管理组件501在推送历史业务数据下发完成后，向业务管理依赖组件502推送下发完成的消息，再继续下发增量业务数据，业务管理依赖组件502在生成目标数据结束前，仍旧将增量业务数据存放在数据管道中，不作处理。在生成目标数据结束后，再从数据管道中取出增量业务数据，根据增量业务数据生成的增量目标数据则在目标链表中的结束标志后依次挂载。
126.业务管理依赖组件502在生成目标数据结束后，随即依次取出目标链表中的目标数据向驱动适配组件503下发，在目标链表中的目标数据全部下发完成后，即目标链表的数据尾指针指向结束标志时，依次取出目标链表中的增量目标数据向驱动适配组件503下发。在下发目标数据和增量目标数据的过程中，对目标链表的使用情况、目标链表中的数据变化趋势进行监测，从而控制增量业务数据的接收速率。
127.假设目标链表最多能够缓存8000个目标数据，设定预设第一数据量为7000，预设第二数据量为0，预设时间为10s，设定预设最大速率和预设最小速率均为每采样定时周期内新增80个目标数据，设立时间为t的计时器，即采样定时周期为t，每当计时器周期到达时，则对目标链表的使用情况、目标链表中的数据变化趋势进行监测，从而控制增量业务数据的接收速率，具体步骤如图10所示，包括：
128.在步骤601中，统计当前目标链表中的目标数据和增量目标数据的总个数为m；统计在一个采样定时周期t内目标链表中所新增存储的增量目标数据的个数i，和从目标链表中所取出的目标数据或增量目标数据的个数j，计算采样定时周期t内的增量目标数据增加的速率为(i-j)/t；其中，当(i-j)/t》0时，说明新增存储的增量目标数据的数量大于从目标链表中取出的目标数据或增量目标数据的数量，目标链表的数据量呈增长趋势，当(i-j)/t《0或(i-j)/t＝0时，则说明新增存储的增量目标数据的数量小于等于从目标链表中取出的目标数据或增量目标数据的数量，目标链表的数据量不增长或呈减少趋势。
129.在步骤602中，判断m是否大于等于7000，其中，7000为预设第一数据量，若m大于预设第一数据量，则判断目标链表中的数据量过多，进入步骤609；否则，进入步骤603，根据目标链表的数据量的变化趋势控制增量业务数据的接收速率。
130.在步骤603中，判断(i-j)/t是否大于等于80，若(i-j)/t≥80，其中80为预设最大速率和预设最小速率，则说明目标链表中的数据量增长速率过快，进入步骤605；否则，说明
目标链表中的数据量增长速率正常，或数据量不增长或减少，则进入步骤604。
131.在步骤604中，清空t1，记录首次不满足(i-j)/t》≥80的时刻为t0；其中t1为首次满足(i-j)/t≥80的时刻，由于(i-j)/t≥80被打破，故清空满足(i-j)/t≥80时的计时，此处清空并非清零，而是将其设为无效，使后续计算的t
2-t1始终大于10；当已记录了t0后，即在t0有效的状态下，在后续计时周期中进入该步骤时，不重新记录t1时刻；进入步骤606。
132.在步骤605中，清空t0，记录首次满足(i-j)/t≥80的时刻为t1；其中t0为首次不满足(i-j)/t≥80的时刻，由于(i-j)/t≥80被满足，故清空不满足(i-j)/t≥80时的计时，此处清空并非清零，而是将其设为无效，使后续计算的t
2-t0始终大于10；当已记录了t1后，即在t1有效的状态下，在后续计时周期中进入该步骤时，不重新记录t1时刻；进入步骤607。
133.在步骤606中，将当前时刻记为t2，判断t
2-t0是否大于等于10，即判断(i-j)/t》80的持续时间是否达到预设时间，若大于等于10，则进入步骤608。
134.在步骤607中，将当前时刻记为t2，判断t
2-t1是否大于等于10，即判断(i-j)/t》80的持续时间是否达到预设时间，若大于等于10，则进入步骤609。
135.在步骤608中，将增量业务数据的接收速率恢复为正常接收速率，具体包括：若当前增量业务数据的接收速率为正常接收速率，则保持正常接收速率，若当前增量业务数据的接收速率为最小接收速率，则恢复为正常接收速率，其中，改变增量业务数据的接收速率是通过改变从增量业务数据的管道中取增量业务数据的定时器的时间间隔实现的，等待进入下一采样定时周期。
136.在步骤609中，将增量业务数据的接收速率降低为最小接收速率，具体包括：若当前增量业务数据的接收速率为最小接收速率，则保持最小接收速率，若当前增量业务数据的接收速率为正常接收速率，则降低为最小接收速率，其中，改变增量业务数据的接收速率是通过改变从下发增量业务数据的管道中取增量业务数据的定时器的时间间隔实现的，等待进入下一采样定时周期。
137.由于将增量业务数据和目标数据均存放在目标链表中，在目标数据下发过程中，目标链表中新增存储的是增量目标数据，取出的是目标数据，通过目标链表的使用情况和数据量变化趋势能够得知业务管理依赖组件502的负载情况和业务管理依赖组件502处理增量目标数据的生成和目标数据的下发这两个过程是否平衡，从而平衡业务管理依赖组件502与单播路由管理组件501的负载，以及保持增量目标数据的生成和目标数据的下发这两个过程的平衡；在目标数据下发完成后，目标链表中新增存储和取出的都是增量目标数据，通过目标链表的使用情况和数据量变化趋势能够得知业务管理依赖组件502的负载情况，从而平衡业务管理依赖组件502与单播路由管理组件501的负载。
138.本发明实施例还包括控制目标数据的下发过程来平衡业务管理依赖组件502与驱动适配组件503之间的负载，与上述实现方式相结合从而平衡系统负载，具体包括：
139.业务管理依赖组件502依次取出所述目标链表中的目标数据，将取出的目标数据下发到目标管道中，向驱动适配组件503从所述目标管道中实时读取目标数据。
140.业务管理依赖组件502监测目标管道中目标数据的数量，设定预设数量为30，预设最小数量为20，若所述目标管道中的目标数据的数量超过30，则将从所述目标链表中取目标数据的速率降低为最小下发速率；若所述目标管道中的目标数据的数量低于20，则将从所述目标链表中取目标数据的速率恢复为正常下发速率。
141.为了更精准地平衡系统的负载，还通过在目标数据的下发过程中引入增量业务数据的数据量来控制增量业务数据的接收速率，具体包括：
142.在预设时间内，若在目标链表中增量目标数据的个数超出预设增量目标数据最大数据量，则将接收增量业务数据的速率降低为最小接收速率，若在目标链表中增量目标数据的个数低于预设增量目标数据最小数据量，则将接收增量业务数据的速率恢复为正常接收速率。
143.其中，预设增量业务数据最大数据量和预设增量业务数据最小数据量是本领域技术人员根据经验分析得出的。
144.由于在数据恢复未结束前，即目标链表中还存在结束标志时，业务管理依赖组件502和驱动适配组件503的主要工作是生成自身的中游业务数据和实现与上游组件的数据同步，即处理历史业务数据，而在数据恢复结束后，即目标数据下发结束后，目标链表中只存在增量目标数据时，业务管理依赖组件502和驱动适配组件503的主要工作是维持系统的正常业务运行，即处理增量业务数据，业务管理依赖组件502和驱动适配组件503处理历史业务数据和处理增量业务数据时的速度可能不同，给组件带来的负载也不同，故可针对数据恢复阶段和正常业务运行阶段分别设定该阶段时的预设第一数据量、预设第二数据量、预设时间、预设最大速率、预设最小速率，由此根据不同阶段的目标链表的使用情况，控制接收增量业务数据的速率，从而实现数据恢复与系统正常运行过程中的整体负载均衡。
145.在本发明实施例中，第一、第二等限定性描述，并非是指代特定顺序含义，仅仅是为了让对应限定的对象能够从同类中脱离出来，并且是为了方便描述同类中不同的两个对象或者多个对象方便而加的限定，不应该将其解释出进一步限定意义。
146.实施例4:
147.本发明实施例提供了一种数据恢复装置。
148.如图11所示，是本发明实施例的数据恢复装置的架构示意图。本实施例的数据恢复装置包括一个或多个处理器21以及存储器22。其中，图11中以一个处理器21为例。
149.处理器21和存储器22可以通过总线或者其他方式连接，图11中以通过总线连接为例。
150.存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的数据恢复方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行数据恢复方法。
151.存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
152.所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1和实施例2中的数据恢复方法，例如，执行以上描述的图2、图4、图5、图7和图10所示的各个步骤。
153.值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
154.本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，read only memory)、随机存取存储器(ram，random access memory)、磁盘或光盘等。
155.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。