一种配置下发方法、电子设备及存储介质与流程

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.所述服务端从所述客户端的配置记录中查询出至少一个配置功能对应的第二配置下发任务；所述第二配置下发任务为所述配置功能中配置状态为未配置的最新版本号对应的配置下发任务；
26.所述服务端将所述第二配置下发任务发送给所述客户端；
27.所述服务端根据所述客户端反馈的所述第二配置下发任务的完成情况，更新所述第二配置下发任务的第二配置状态。
28.上述技术方案中，客户端可以基于自身的实际需求向服务端发送配置获取请求，比如客户端需要自身所需配置的至少一个配置功能中最新版本号的配置下发任务进行配置，也即是，至少一个配置功能的最新版本号的配置下发任务在下发过程中遇到异常情况，该客户端针对至少一个配置功能的最新版本号的配置下发任务没有及时固化或固化失败，此时会生成增量配置下发请求并向服务端发送增量配置下发请求，以使服务端通过在该客户端的配置记录中有针对性地查询出多个配置功能中配置状态为未配置的最新版本号对应的配置下发任务，并将该多个配置功能中配置状态为未配置的最新版本号对应的配置下发任务及时地下发给该客户端，以便使得该客户端能够及时有效地获取到多个配置功能中的最新配置，如此可以有针对性地满足该客户端的真实需求，而非盲目的、一味的将服务端存储的各配置功能的各配置下发任务(包括最新版本号以及以往各版本号)均下发给该客户端，从而可以使得服务端下发配置下发任务更加具有针对性，且灵活性更高，以此实现针对客户端的配置下发任务进行按照客户端的需求进行下发的目的，同时可以最大限度地减少在配置下发的过程中的传输数据量。
29.可选地，还包括：
30.针对任一客户端，所述服务端接收所述客户端的全量配置下发请求；
31.所述服务端从所述客户端的配置记录中，获取各配置功能的最新版本号的各配置下发任务；
32.所述服务端将所述各配置功能的最新版本号的各配置下发任务发送给所述客户端；
33.所述服务端根据所述客户端反馈的所述各配置下发任务的完成情况，更新所述各配置下发任务的配置状态。
34.上述技术方案中，客户端可以基于自身的实际需求向服务端发送配置获取请求，比如客户端需要自身所需配置的各配置功能的最新版本号的各配置下发任务进行配置，也即是，各配置功能的最新版本号的配置下发任务在下发过程中遇到异常情况(比如网络异常等)，该客户端针对各配置功能的最新版本号的配置下发任务没有及时固化，或者人为修改客户端的配置未及时恢复或人为修改客户端的配置在恢复后与原有配置不一致等，需要全量配置纠正此类错误，此时会生成全量配置下发请求并向服务端发送全量配置下发请求，以使服务端从该客户端的配置记录中查询出各配置功能的最新版本号的各配置下发任务，并将各配置功能的最新版本号的各配置下发任务及时地下发给该客户端，可以确保客户端中各配置功能的最新配置与服务端所存储的客户端的各配置功能的最新配置完全一致。
35.第二方面，本发明实施例还提供了一种配置下发方法，包括：
36.客户端接收服务端发送的第一配置下发任务；所述第一配置下发任务中包括所述配置功能的第一版本号；所述第一配置下发任务是所述服务端针对任一配置功能，在接收到所述配置功能的配置信息后生成，且在确定从所述客户端的配置记录中查询出的所述客户端针对所述第一配置下发任务的第一配置状态为未配置时下发的；所述配置功能的各版本号用于确定所述配置功能的各配置信息变化的先后顺序；
37.所述客户端在确定所述第一版本号优先于所述客户端中所述配置功能的第二版本号时，执行所述第一配置下发任务；
38.所述客户端将所述第一配置下发任务的完成情况反馈给所述服务端；所述服务端用于根据所述第一配置下发任务的完成情况，更新所述第一配置状态。
39.上述技术方案中，客户端在接收到服务端下发的第一配置下发任务后，即可在确定第一版本号优先于客户端中配置功能的第二版本号时，才执行该第一配置下发任务，如此可以避免客户端针对同一最新版本号的配置下发任务进行重复配置，以此可以有效地提高客户端的配置效率。同时，在执行完第一配置下发任务后，需要将该第一配置下发任务的完成情况反馈给该客户端，以便服务端能够及时地获知该客户端是否已固化或已执行该第一配置下发任务，从而确定是否需要重新向该客户端下发该第一配置下发任务，而非不管客户端针对配置下发任务是否真的需要，都定时地重复向客户端发送全量配置，如此，可以实现针对客户端的配置下发任务进行按照客户端的需求进行下发的目的。
40.可选地，所述客户端将所述第一配置下发任务的完成情况反馈给所述服务端，包括：
41.所述客户端在接收到所述第一配置下发任务时，生成固化结果，并将所述固化结果反馈给所述服务端；所述固化结果中包含版本号；以及，
42.所述客户端在执行完所述第一配置下发任务时，生成执行结果，并将所述执行结果反馈给所述服务端；所述执行结果中包含版本号。
43.上述技术方案中，客户端在接收到该第一配置下发任务后，会生成固化结果，并将该固化结果反馈给服务端，以便服务端及时地获知该客户端是否已经成功接收该第一配置下发任务，并在该客户端已经成功接收该第一配置下发任务时，服务端无需向该客户端重
复下发，也即是，服务端可以通过该固化结果避免向该客户端重复下发该第一配置下发任务。以及，客户端在执行完该第一配置下发任务后，会生成执行结果，并将该执行结果反馈给服务端，以便服务端及时地获知该客户端是否已经成功执行该第一配置下发任务，也即是便于服务端及时地获知该客户端针对第一配置下发任务的真实执行情况。
44.可选地，还包括：
45.所述客户端在检测到第一设定时间到达时，生成增量配置下发请求；
46.所述客户端将所述增量配置下发请求发送给所述服务端；所述增量配置下发请求用于指示所述服务端从所述客户端的配置记录中查询出至少一个配置功能对应的第二配置下发任务，并将所述第二配置下发任务发送给所述客户端；所述第二配置下发任务为所述配置功能中配置状态为未配置的最新版本号对应的配置下发任务。
47.上述技术方案中，客户端在第一设定时间到达时，会基于自身需求生成增量配置下发请求，并将该增量配置下发请求发送给服务端，以便服务端根据存储的该客户端的配置记录，有针对性地查询出多个配置功能中配置状态为未配置的最新版本号对应的配置下发任务，并将该多个配置功能中配置状态为未配置的最新版本号对应的配置下发任务及时地下发给该客户端，以便使得该客户端能够及时有效地获取到多个配置功能中的最新配置，以此有针对性地满足该客户端的真实需求，从而可以使得服务端下发配置下发任务更加具有针对性，且灵活性更高，以此实现针对客户端的配置下发任务进行按照客户端的需求进行下发的目的。
48.可选地，还包括：
49.所述客户端在检测到第二设定时间到达时，生成全量配置下发请求；
50.所述客户端将所述全量配置下发请求发送给所述服务端；所述全量配置下发请求用于指示所述服务端从所述客户端的配置记录中，获取各配置功能的最新版本号的各配置下发任务，并将所述各配置功能的最新版本号的各配置下发任务发送给所述客户端。
51.上述技术方案中，客户端在第二设定时间到达时，会基于自身需求生成全量配置下发请求，并将该全量配置下发请求发送给服务端，以便服务端根据存储的该客户端的配置记录，查询出各配置功能的最新版本号的配置下发任务，并将各配置功能的最新版本号的各配置下发任务及时地下发给该客户端，可以确保客户端中各配置功能的最新配置与服务端所存储的客户端的各配置功能的最新配置完全一致。
52.第三方面，本发明实施例提供一种电子设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述第一方面或第二方面任意所述的配置下发方法。
53.第四方面，本发明实施例提供一种计算机可读存储介质，其存储有可由电子设备执行的计算机程序，当所述程序在所述电子设备上运行时，使得所述电子设备执行上述第一方面或第二方面任意所述的配置下发方法。
附图说明
54.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他
的附图。
55.图1为本发明实施例提供的一种可能的系统架构示意图；
56.图2为本发明实施例提供的一种配置下发方法的流程示意图；
57.图3为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
58.为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
59.为了便于理解本发明实施例，首先以图1中示出的一种可能的系统架构为例说明适用于本发明实施例的配置下发系统架构。该可能的系统架构可以应用于一个服务端与一个客户端之间的配置下发场景，或者可以应用于一个服务端与多个客户端之间的配置下发场景，或者可以应用于多个服务端与多个客户端之间的配置下发场景等，本发明实施例对此并不作限定。如图1所示，以一个服务端与一个客户端为例进行描述，该可能的系统架构可以包括服务端100和客户端200。其中，服务端100(比如服务器)和客户端200所在的终端设备(比如智能手机、平板电脑、笔记本电脑、台式电脑或智能可穿戴设备等)之间可以进行通信连接，比如，可以通过有线网络方式连接，或者可以通过无线网络方式连接，本发明实施例对此并不作限定。需要说明的是，只要是能够提供相关服务的设备或应用程序软件等都可以作为服务端，只要是需要接收相关服务的设备或应用程序软件等都可以作为客户端。示例性地，以服务器作为服务端，台式电脑上安装的web客户端为例，在服务器接收到针对web客户端的某一配置功能(比如路由功能、数据展示功能或数据渲染功能等)的配置信息后，即可生成携带有最新版本号的配置任务，并针对任一web客户端，在该web客户端的配置记录中查询到该web客户端针对携带有最新版本号的配置任务的配置状态为未配置时，将携带有最新版本号的配置任务下发给该web客户端，以使该web客户端针对携带有最新版本号的配置任务进行相应的处理。
60.需要说明的是，上述图1所示的系统结构仅是一种示例，本发明实施例对此不做限定。
61.基于上述描述，图2示例性的示出了本发明实施例提供的一种配置下发方法的流程，该流程可以由服务端和客户端交互执行。下面以一个服务端和一个客户端进行交互执行配置下发方法为例进行描述。
62.如图2所示，该流程具体包括：
63.步骤201，针对任一配置功能，服务端在接收到所述配置功能的配置信息后，生成第一配置下发任务。
64.本发明实施例中，一个客户端通常会设置有多个配置功能，例如，路由功能、存储功能等，在初始状态下，各配置功能的状态为初始化的配置状态，比如，路由功能的初始化状态为关闭状态。在实际应用中，技术人员需要根据业务场景或客户需求对该多个配置功能中全部配置功能或一部分配置功能的配置信息进行更新。具体地，针对任一配置功能(比如路由功能)，技术人员可通过服务端提供的配置界面下发相应的配置信息，以实现对全部
或部分客户端的控制；服务端在接收到技术人员下发的针对该配置功能的配置信息后，可以根据该下发的配置信息生成第一配置下发任务。其中，第一配置下发任务中可以包括配置功能的第一版本号；该配置功能的各版本号用于确定服务端接收到该配置功能的各配置信息的先后顺序。
65.示例性地，以配置功能为路由功能为例，且为了方便介绍本发明实施例中的技术方案，以路由功能的配置信息为开启路由和关闭路由的操作为例，可以理解的是配置功能的配置信息可根据不同的业务需求进行设定。
66.客户端在完成初始化后，服务端针对各客户端的各配置功能的初始配置信息预先创建并存储有配置记录表，记录表中包含配置信息、版本号、固化结果和执行结果等字段，其中，固化结果和执行结果用于记录客户端对该配置信息的接收和执行状态。如表1a所示，服务端记录有某一客户端的路由功能配置记录，该配置记录对应该客户端在初始状态下的路由功能配置信息，其中显示的固化结果和执行结果为已固化和已执行，表示该客户端已处于初始状态，即路由关闭状态。
67.表1a
[0068][0069]
相应地，该客户端在初始化后，可在本地创建并存储针对路由功能的配置记录，如表1b所示，已记录完成执行的配置信息及版本号。
[0070]
表1b
[0071][0072]
在客户端初始完成后，当服务端接收到技术人员等下发的针对该客户端的路由功能的开启配置信息后，可生成针对该路由功能的开启配置下发任务，确定该配置信息对应的版本号为002，并记录在先前创建的记录表中，如表2a所示，在表中新增一条记录。
[0073]
表2a
[0074][0075][0076]
需要说明，如果在服务端发生数据回滚等异常情况，那么在服务端也就不会存在如表2a所示的针对该类客户端的路由功能配置记录，当然该类客户端也就不会接收到开启配置下发任务。
[0077]
步骤202，针对任一客户端，所述服务端在所述客户端的配置记录中查询出所述客户端针对所述第一配置下发任务的第一配置状态。
[0078]
步骤203，在确定所述第一配置状态为未配置时，所述服务端发送所述第一配置下发任务给所述客户端。
[0079]
本发明实施例中，技术人员可将同一配置功能的同一配置信息指定下发给至少一个客户端。服务端在接收到该下发的配置信息后，确定出该配置信息的版本号，生成第一配置下发任务，并在本地所存储的客户端的配置记录中分别查询各客户端对应的第一配置下发任务的状态，具体而言，服务端通过查询客户端的配置信息记录表，确定出该记录表中是否有该配置信息对应的记录，若不存在该配置信息的记录，则确定该客户端针对所述第一配置下发任务的第一配置状态为未配置状态，同时在表中新增该配置信息对应的记录；若记录表中已存在该记录，则继续确定该记录中的固化结果，如果固化结果为未固化，则可确定该客户端针对所述第一配置下发任务的第一配置状态为未配置，若固化结果显示为已固化，则确定该客户端针对所述第一配置下发任务的第一配置状态为已配置。
[0080]
该客户端a针对路由功能的开启配置可以如表2b所示。
[0081]
如果该客户端a的配置记录中记录该客户端a针对该开启配置下发任务的配置状态为未配置，也即是，该客户端a针对该携带有版本号002的开启配置下发任务的固化结果为未固化且执行结果为未执行，则需要将该携带有版本号002的开启配置下发任务下发该客户端a。
[0082]
步骤204，所述客户端在确定所述第一版本号优先于所述客户端中所述配置功能的第二版本号时，执行所述第一配置下发任务。
[0083]
步骤205，所述客户端反馈所述第一配置下发任务的完成情况给所述服务端。
[0084]
本发明实施例中，该客户端在接收到服务端发送的第一配置下发任务后，可先对第一配置下发任务进行固化，即在将该第一配置下发任务中的配置信息和版本号进行记录，如表2b。
[0085]
表2b
[0086][0087]
同时，在完成固化后，可先向服务端反馈固化结果，使得服务端基于接收的固化结果对本地记录进行更新。
[0088]
客户端在对配置信息进行固化后，需进一步执行该配置信息，可以理解的是，由于各种因素，客户端执行配置信息的时间是不确定的，当客户端开始执行配置信息对应的操作时，客户端中可能已保存了多条待执行的配置记录，因此可能会出现待执行的配置信息中存在不同版本的情况，客户端在执行配置信息前，需确定当前执行的配置信息的版本，在确定该第一配置下发任务中所包含的第一版本号优先于本地记录中该配置功能的第二版本号时，开始执行该第一配置下发任务，即执行第一配置下发任务中的配置信息指示的操作，在执行完成后，将执行该第一配置下发任务的完成情况反馈给服务端。一般而言，针对同一配置功能的不同配置信息，后下发的配置信息版本优先于先下发的配置信息版本，比如版本号002高于版本号001，当客户端待执行的配置信息中存在多个不同版本，可直接执行高版本的操作即可，其他低版本的操作可忽略。由此可见，服务端在设定配置信息的版本号时需基于配置操作的具体内容进行设定，在本技术的其他实施例中，也可以通过设置优先级的方式来确定不同配置信息间的执行顺序。
[0089]
当客户端完成配置信息的操作后，可记录该配置信息的执行状态。
[0090]
步骤206，所述服务端根据所述客户端反馈的所述第一配置下发任务的完成情况，更新所述第一配置状态。
[0091]
本发明实施例中，任务的完成情况包含固化结果和执行结果。服务端在接收到该客户端反馈的固化结果后，该固化结果包含针对该配置功能的版本号，如果确定该客户端反馈的固化结果为未固化或固化失败，则不会对该客户端的配置记录中第一配置下发任务的固化结果的配置状态进行更新，也即是说，在确定该客户端反馈的固化结果为未固化或固化失败时，无论固化结果中的版本号是否与第一版本号一致，都不会对该客户端的配置记录中第一配置下发任务的固化结果的配置状态进行更新。如果确定该客户端反馈的固化结果为固化成功(即已固化完成)，则才会在确定固化结果中的版本号与第一版本号一致时，将该客户端的配置记录中第一配置下发任务的固化结果的配置状态更新为已固化。如此，通过客户端反馈的固化结果，可以便于服务端及时地获知该客户端是否已经成功接收该第一配置下发任务，并在该客户端已经成功接收该第一配置下发任务时，无需向该客户端重复下发，也即是可以通过该固化结果避免向该客户端重复下发该第一配置下发任务。
[0092]
此外，服务端在接收到该客户端反馈的执行结果后，如果确定该客户端反馈的执行结果为未执行或执行失败，则不会对该客户端的配置记录中第一配置下发任务的执行结果的配置状态进行更新，也即是说，在确定该客户端反馈的执行结果为未执行或执行失败时，无论执行结果中的版本号是否与第一版本号一致，都不会对该客户端的配置记录中第一配置下发任务的执行结果的配置状态进行更新。如果确定该客户端反馈的执行结果为执行成功(即已执行完成)，则才会在确定执行结果中的版本号与第一版本号一致时，将该客户端的配置记录中第一配置下发任务的执行结果的配置状态更新为已执行。如此，可以便于服务端通过该客户端反馈的执行结果及时地获知该客户端是否已经成功执行该第一配置下发任务，也即是便于服务端及时地获知该客户端针对第一配置下发任务的真实执行情况。
[0093]
此外，在更新完第一配置状态之后，如果某一客户端的第一配置下发任务的第一配置状态为已固化且已执行，则可以先将缓存的该客户端的配置记录中的第一配置下发任务进行删除标记(即逻辑删除)，后续在接收到该客户端针对该第一配置下发任务的删除指令后方可进行真实删除(即物理删除)，如此可以确保该客户端在某种情况下(比如人为故意上报已执行但并未真实执行或人为故意上报已固化但并未真实固化等)需要该第一配置下发任务时能够及时准确地获取到该第一配置下发任务，以此避免在客户端需要该第一配置下发任务的配置时因将该第一配置下发任务进行真实删除而无法获取该第一配置下发任务。也即是，在接收到该客户端针对该第一配置下发任务的删除指令后，即可表明该客户端已经成功完成该第一配置下发任务的配置，可以直接针对该客户端的第一配置下发任务进行真实删除。如此，可以有助于释放服务端的内存，降低无用的内存占用，以此有效地缓解服务端的内存压力。
[0094]
示例性地，继续以客户端a为例，如果该客户端a反馈的是固化失败或未固化的固化结果，则服务端对该客户端a的配置记录中针对路由功能的配置记录的固化结果仍然保持为未固化，不会进行更新。如果该客户端a反馈的是固化成功的固化结果，则服务端在确定该固化结果的版本号002与该客户端a的配置记录中针对路由功能的配置记录中的版本号002一致时，将该客户端a的配置记录中针对路由功能的配置记录的固化结果更新为已固
化，即如表3所示的更新固化结果后的针对客户端a的路由功能的配置记录。
[0095]
表3
[0096][0097]
以及，如果该客户端a反馈的是执行失败或未执行的执行结果，则服务端对该客户端a的配置记录中针对路由功能的配置记录的执行结果仍然保持为未执行，不会进行更新。如果该客户端a反馈的是执行成功的执行结果，则服务端在确定该执行结果的版本号002与该客户端a的配置记录中针对路由功能的配置记录中的版本号002一致时，将该客户端a的配置记录中针对路由功能的配置记录的执行结果更新为已执行，即如表4所示的更新执行结果后的针对客户端a的路由功能的配置记录。
[0098]
表4
[0099][0100]
此外，如果出现客户端因为某种原因未反馈固化结果或反馈固化失败或反馈未固化的情况，则此时该客户端在第一设定时间(比如每间隔1秒、2秒、3秒、5秒、10秒、20秒或20秒以上等)到达时，会基于自身需求生成增量配置下发请求，并将该增量配置下发请求发送给服务端，以便服务端根据存储的该客户端的配置记录，有针对性地查询出多个配置功能中配置状态为未配置的最新版本号对应的配置下发任务(即第二配置下发任务)，并将处于未配置状态的每个配置功能对应的第二配置下发任务及时地下发给该客户端，以便使得该客户端能够及时有效地获取到多个配置功能中的最新配置，以此有针对性地满足该客户端的真实需求，从而可以使得服务端下发配置下发任务更加具有针对性，且灵活性更高，以此实现针对客户端的配置下发任务进行按照客户端的需求进行下发的目的。同时，针对每个第二配置下发任务，该客户端也会在确定该第二配置下发任务中所包含的版本号优先于该客户端中该第二配置下发任务所对应的配置功能的版本号时执行该第二配置下发任务，并将执行该第二配置下发任务的完成情况反馈给服务端，以便服务端根据该客户端反馈的该第二配置下发任务的完成情况，更新该客户端的配置记录中针对该第二配置下发任务的第二配置状态。需要说明的是，客户端针对增量配置下发请求的频率较高，比如正常秒级或分钟级，具体可以根据系统的敏感程度进行动态调整。其中，增量配置下发请求所获取的是固化结果为未固化/固化失败/逻辑删除的最新版本号的配置下发任务。
[0101]
再者，如果出现客户端因为某种原因未反馈固化结果或反馈固化失败或反馈未固化的情况，或者人为修改客户端的配置未及时恢复或人为修改客户端的配置在恢复后与原有配置不一致等，需要全量配置纠正此类错误，则此时该客户端在第二设定时间(比如每间隔1天、2天、一周或一周以上等)到达时，会基于自身的实际需求(比如客户端需要自身所需配置的各配置功能的最新版本号的各配置下发任务进行配置)生成全量配置下发请求，并将该全量配置下发请求发送给服务端，以使服务端从该客户端的配置记录中查询出各配置功能的最新版本号的各配置下发任务，并将各配置功能的最新版本号的各配置下发任务及时地下发给该客户端，可以确保客户端中各配置功能的最新配置与服务端所存储的客户端
的各配置功能的最新配置完全一致。同时，针对每个配置下发任务，该客户端也会在确定该配置下发任务中所包含的版本号优先于该客户端中该配置下发任务所对应的配置功能的版本号时执行该配置下发任务，并将执行该配置下发任务的完成情况反馈给服务端，以便服务端根据该客户端反馈的该配置下发任务的完成情况，更新该客户端的配置记录中针对该配置下发任务的配置状态。需要说明的是，客户端针对增量配置下发请求的频率较低，比如正常天级、周级或月级。其中，全量配置下发请求所获取的是全部已固化/未固化/固化失败/逻辑删除的最新版本号的配置下发任务。而且，全量配置下发请求可以为兜底方案，请求频率在一天、一周或一个月等都可以。
[0102]
如此，上述技术方案在针对出现网络异常(比如断网)或配置下发任务传输异常的过程中可能任一个或任意多个配置下发任务的版本号已经跨多版本的情况时，只需要客户端执行增量/全量配置同步，均可以获取到最新版本号对应的最新配置，即使在传输多个最新配置的过程中出现消息错乱，因为有版本号限制，因此通过固化结果/执行结果均能确保任一配置功能的最新版本号的最新配置不会错乱。而且，就算某一客户端或某几个客户端在下发针对某一配置功能的配置下发任务时处于离线状态，但是，只有该客户端或该几个客户端重新上线，并向服务端发送配置下发请求，则获取的都是最新版本号对应的最新配置。所以，该方案在正常情况下针对任一配置功能的每个版本的配置只需下发一次即可完成配置，无需重复下发。但是对于特殊情况(比如客户端反馈不及时或网络异常等)需要同步获取(比如增量同步或全量同步)的，也只是获取该配置功能的最新版本号对应的最新配置，以此最大限度地减少在配置下发的过程中的传输数据量，以此可以有效地提高配置下发的传输效率。
[0103]
上述实施例表明，本发明中的技术方案通过服务端及时地查询任一客户端针对生成的配置下发任务的需求，并基于客户端的需求及时地向需要配置下发任务的客户端发送相应的配置下发任务，也即是只下发客户端所需要的配置下发任务，同时在确定配置下发任务下发成功后不会再主动地向客户端重复发送已经下发的配置下发任务，而非不管客户端针对配置下发任务是否真的需要，都定时地重复向客户端发送全量配置，如此，可以实现针对客户端的配置下发任务进行按照客户端的需求进行下发的目的，同时可以最大限度地减少在配置下发的过程中的传输数据量，以此可以有效地提高配置下发的传输效率。具体来说，针对任一配置功能，服务端在接收到该配置功能的配置信息后，生成第一配置下发任务，并针对任一客户端，在该客户端的配置记录中查询该客户端针对第一配置下发任务的第一配置状态，如果确定该第一配置状态为未配置，则将第一配置下发任务发送给该客户端，其中，第一配置下发任务中包括该配置功能的第一版本号；该配置功能的各版本号用于确定该配置功能的各配置信息变化的先后顺序。然后，根据该客户端反馈的第一配置下发任务的完成情况，更新该第一配置状态。其中，客户端用于在确定第一版本号优先于该客户端中该配置功能的第二版本号时执行第一配置下发任务。如此，该方案可以基于客户端的需求只需下发一次配置下发任务即可及时准确地完成针对客户端的配置下发，而无需重复地向客户端发送全量配置，可以有助于最大限度地减少在配置下发的过程中的传输数据量，从而可以有效地提高配置下发的传输效率，并可以有效地提高在配置下发的过程中所使用的传输通道的利用率。
[0104]
基于相同的技术构思，本发明实施例还提供了一种电子设备，如图3所示，包括至
少一个处理器301，以及与至少一个处理器连接的存储器302，本发明实施例中不限定处理器301与存储器302之间的具体连接介质，图3中处理器301和存储器302之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。
[0105]
在本发明实施例中，存储器302存储有可被至少一个处理器301执行的指令，至少一个处理器301通过执行存储器302存储的指令，可以执行前述的配置下发方法中所包括的步骤。
[0106]
其中，处理器301是电子设备的控制中心，可以利用各种接口和线路连接电子设备的各个部分，通过运行或执行存储在存储器302内的指令以及调用存储在存储器302内的数据，从而实现数据处理。可选的，处理器301可包括一个或多个处理单元，处理器301可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理下发指令。可以理解的是，上述调制解调处理器也可以不集成到处理器301中。在一些实施例中，处理器301和存储器302可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
[0107]
处理器301可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合配置下发方法实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0108]
存储器302作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器302可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(random access memory，ram)、静态随机访问存储器(static random access memory，sram)、可编程只读存储器(programmable read only memory，prom)、只读存储器(read only memory，rom)、带电可擦除可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、磁性存储器、磁盘、光盘等等。存储器302是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器302还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
[0109]
基于相同的技术构思，本发明实施例还提供了一种计算机可读存储介质，其存储有可由电子设备执行的计算机程序，当所述程序在所述电子设备上运行时，使得所述电子设备执行上述配置下发方法的步骤。
[0110]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0111]
本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或
方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0112]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0113]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0114]
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
[0115]
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。