CN108156015B - 数据的更新方法和装置 - Google Patents

Abstract

本申请提供一种数据的更新方法及装置，该方法应用在转发设备上，包括：接收服务器下发的配置数据；基于所述配置数据的下发模式，及缓存中存储的配置数据和当前版本信息，对转发设备中的配置数据进行更新；其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。通过本申请的技术方案，解决了现有技术中的问题，能够确保增量下发模式下配置数据的幂等性和正确性，并保证全量下发模式下配置数据的稳定一致性，保证不丢包，不断流。

Description

数据的更新方法和装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据的更新方法和装置。

背景技术

现有技术中，数据网络中的转发设备任何时刻都承载着用户的流量，如果转发设备的转发表项在某一时刻丢失，会造成用户数据断流。然而，在虚拟网络中，用户自定义网络的需求较大，导致管控系统频繁下发各种表项，因而造成表项丢失的概率较大，进而导致流量中断。这种情况下通常以增量下发模式来下发配置数据，而较为频繁的下发可能又会导致一些其他异常，例如，管控系统下发的配置数据中的表项出现错误，转发设备判断为不合法，或者操作系统卡住，导致下发不成功等，这种情况下增量下发模式不能解决上述问题。如果采用全量下发模式，在下发配置数据时，每次下发都将需要配置特性的相关表项全部下发一遍，然后重新配置对应的表项，在频繁改变表项的情况下这种下发模式会消耗大量的网络资源，导致收发端的数据不能够保证稳定一致。

发明内容

本申请提供数据的更新方法及装置，以解决现有技术在下发配置数据时不能保证幂等性、容易出现断流、数据不能保持稳定一致等问题。

根据本申请实施例的第一方面，提供一种数据的更新方法，应用在转发设备上，包括：

接收服务器下发的配置数据；

基于所述配置数据的下发模式，及缓存中存储的配置数据和当前版本信息，对所述转发设备中的配置数据进行更新；

其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

根据本申请实施例的第二方面，提供了一种数据的更新装置，应用在服务器上，包括：

接收单元，用于接收服务器下发的配置数据；

第一更新单元，用于基于所述配置数据的下发模式，及缓存中存储的配置数据和当前版本信息，对所述转发设备中的配置数据进行更新；其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

根据本申请实施例的第三方面，提供一种转发设备，包括：

数据接收模块，用于接收所述服务器下发的配置数据；

缓存模块，用于缓存基于所述服务器上一次下发的配置数据进行更新之后得到的配置数据；

版本管理模块，用于存储所述转发设备存储的配置数据的当前版本信息；

处理模块，与所述数据接收模块、所述缓存模块及所述版本管理模块连接，用于基于所接收到的配置数据的下发模式，及所述缓存模块中存储的配置数据和所述当前版本信息，对所述转发设备中的配置数据进行更新。

根据本申请实施例的第四方面，提供一种数据的更新装置，所述设备为服务器，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为：

接收服务器下发的配置数据；

基于所述配置数据的下发模式，及缓存中存储的配置数据和当前版本信息，对所述转发设备中的配置数据进行更新；

其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

由以上技术方案可见，本申请的实施例中转发设备接收服务器下发的配置数据，然后基于配置数据的下发模式，及缓存中存储的配置数据和当前版本信息对转发设备中的配置数据进行更新。其中缓存(Cache)设置在转发设备的中间件中，用于存储服务器每次下发配置数据之后的最终配置数据和当前版本信息。从而，通过对比缓存中存储的当前版本信息及接收的配置数据的版本信息，能够保证增量下发模式下的配置数据的幂等性，保证配置数据下发正确；并且通过对比全量下发模式下发的配置数据和缓存中存储的配置数据的差异，对转发设备中的配置数据进行更新，能够保证配置数据的一致性。

附图说明

图1A是本申请实施例中数据的更新方法的场景示意图；

图1B是本申请实施例的转发设备的模块示意图；

图2是本申请实施例中数据的更新方法的一个实施例流程图；

图3是本申请实施例中数据的更新方法的另一个实施例流程图；

图4是本申请实施例中数据的更新装置所在设备的一种硬件结构图；

图5是本申请实施例中数据的更新装置的一个实施例框图。

具体实施方式

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

现有技术中，增量下发模式指的是仅下发发生改变的配置数据，而不下发未发生改变的配置数据，在出现错误时，清空底层设备上的所有配置数据，并重新配置所有的配置数据。对于增量下发模式，较为灵活，但是容错性低，而且由于虚拟网络中的管控系统大多通过多线程操作，或者多机互备，这使得一个数据变更可能会带来两次重复的下发，这样可能会导致第二次下发失败，例如当需要修改数据时下发的请求为删除和修改，因而第二次重复下发该请求时该条数据已经被删除，从而导致下发失败，返回的响应不一样，因而不能保证幂等性，容易出错。

全量下发模式指的是每次下发都将包括需要配置特性的数据及不需要配置特性的数据的全部配置数据下发一次，然后将对应属性的配置数据进行重新配置。对于全量下发模式，在转发设备的配置数据不经常改变的情况下，这种方式能够保证配置数据的正确下发。但是在虚拟网络环境中，由于用户自定义网络非常频繁，因而转发设备的配置数据可能时刻都在改变，这种情况下，每次下发的配置数据中可能带有大量的无用数据，例如仅需要改变一个限速值，就需要将转发设备上的相应数据全部清空，并下发全部配置数据，于是在接收端和发送端需要更多的数据编解码工作，因而会消耗更多的处理资源和网络资源，而且不能保证网络的稳定性，很可能导致用户端出现流量中断。

本申请的实施例提出一种新的数据的更新方法及装置，通过在转发设备中设置缓存，存储服务器下发的配置数据及当前版本信息。对于服务器下发的配置数据，基于配置数据的下发模式，结合缓存中的配置数据和当前版本信息来对转发设备中的配置数据进行更新。通过对比版本的方式更新增量下发模式下发的配置数据，能够保证多次下发的配置数据的幂等性和准确性；通过对比缓存中的配置数据和全量下发模式下发的配置数据的差异，能够保证配置数据的一致性和下发的稳定性，实现在用户无感知不丢包的情况下的配置数据的更新。

本申请的实施例可以应用于转发设备中，例如网关、路由器等设备。

参见图1A，为本申请实施例的数据的更新方法的场景示意图：图1A中包括：服务器，通过网络与服务器连接的转发设备，转发设备的中间件中设置有缓存，缓存中用于存储服务器上一次下发配置数据之后的最终配置数据，即基于上一次下发的配置数据更新后的最终配置数据。其中服务器即管控系统，通常管控系统包括多个服务器，图1A中仅示出一个服务器为例进行说明。转发设备可以是设置在覆盖(overlay)虚拟网络中的中间转发设备，该转发设备基于通用服务器作为硬件基础，结合软件来实现overlay虚拟网络下的转发功能，其硬件基础可以例如：x86、x64、ARM(Advanced RISC Machine，进阶精简指令集机器)、Power、PPC(Pocket PC，掌上电脑)等架构。

参见图1B，为本申请实施例的转发设备的模块示意图，图1B中包括：数据接收模块11、处理模块12、回复模块13、缓存模块14和版本管理模块15。

其中，数据接收模块11，被配置为建立Http(Hyper Text Transfer Protocol，超文本传输协议)服务器，该Http服务器接收管控系统下发的配置数据，并将接收到的配置数据传递给转发设备的接收队列进行存储；该数据接收模块11为独立的线程。

处理模块12，被配置为获取接收队列中存储的配置数据，并对获取到的配置数据进行解析，然后在增量下发模式下，调用版本管理模块15以确定当前版本信息，通过对比增量下发模式下发的第一配置数据的版本信息(通过解析得到)和当前版本信息，来确定是否需要更新转发设备中的配置数据；以及在全量下发模式下，调用缓存模块14存储的配置数据，并基于全量下发模式下的第二配置数据和缓存模块14中存储的配置数据的差异更新转发设备上对应的配置数据，以及将配置更新的结果写入到转发设备的回复队列；此外处理模块12还被配置为调用版本管理模块15的当前版本信息来更新配置数据的当前版本。

回复模块13，被配置为对回复队列里的配置数据的更新结果进行编程处理，并将处理结果回复给管控系统。

缓存模块14，设置在转发设备上，用于缓存基于管控系统上一次下发的配置数据进行更新之后的最终配置数据。

版本管理模块15，被配置为存储配置数据的当前版本信息，以便处理模块12根据第一配置数据的第一版本信息与当前版本信息的差异来判断是否需要更新配置数据。

由上述结构可以看出，与现有技术相比，本申请提供的转发设备增设了缓存模块14，用于存储基于服务器上一次下发的配置数据进行更新之后的最终配置数据。在接收到增量下发模式下发的第一配置数据时，通过对比第一配置数据的第一版本信息和当前版本信息，仅当第一版本信息高于当前版本信息一个等级时，对转发设备中对应的配置数据进行更新，从而保证增量下发模式下多次下发的配置数据的幂等性；在增量下发模式下发失败时，并不清空缓存模块14中的配置数据，并且接收到全量下发模式下发的第二配置数据时，通过对比缓存模块14中存储的配置数据和第二配置数据的差异，删除转发设备中未更新的配置数据，从而实现全量下发模式下的不断流。

应用在转发设备上的数据的更新方法的流程如图2所示，包括以下步骤：

步骤201、接收服务器下发的配置数据。

其中，服务器可以一次下发多条配置数据，配置数据的具体数量根据实际情况而定，本申请的更新方法对多条配置数据逐条进行处理，配置数据至少包括表项数据。本申请实施例中，服务器在下述情况下会下发配置数据：

1)初始化转发设备：例如转发设备在初次使用的情况下，由于该转发设备上没有任何数据，因而需要对转发设备上的数据进行配置。

2)转发设备上的配置数据出错：这种情况下需要重新下发配置数据对转发设备上的出错的配置数据进行更新。

3)要配置新的配置数据：例如在用户对配置数据进行了自定义的情况下，需要下发该自定义的新的配置数据，以更新转发设备上的配置数据。

本申请实施例中，在转发设备中设置有接收队列，用于存储接收到的配置数据，也就是说转发设备在接收到配置数据后，将配置数据写入到接收队列中。

步骤202、判断接收到的配置数据为全量下发模式还是增量下发模式，如果判断为增量下发模式，执行步骤203，如果判断为全量下发模式，执行步骤205。

本申请实施例中，服务器下发的配置数据具有自定义的协议格式，例如，配置数据中携带有全量下发模式或增量下发模式的下发模式标识，用于标记该配置数据的下发模式类型，转发设备基于配置数据中的相应标识即可判断该配置数据的下发模式为增量下发模式还是全量下发模式。本申请实施例中，为了描述方便，将以增量下发模式下发的配置数据称之为第一配置数据，将以全量下发模式下发的配置数据称之为第二配置数据。

步骤203、基于增量下发模式下发的第一配置数据的版本信息更新转发设备上对应的配置数据。

结合图3所示，对本申请步骤203进行详细说明。

步骤2031、读取第一配置数据的第一版本信息，并读取缓存中存储的当前版本信息。

由上述步骤可知，服务器对下发的配置数据有自定义的协议格式，该协议格式除了包括下发模式，还包括版本信息，通过对第一配置数据进行解析，能够得到第一配置数据的第一版本信息。

本申请实施例中，缓存中不仅存储有基于服务器上次下发的配置数据进行更新后得到的最终配置数据，还存储有当前版本信息，即所存储的配置数据的版本信息。为了便于与缓存中所存储的当前版本信息相区分，将第一配置数据的版本信息称之为第一版本信息。

步骤2032、基于第一配置数据的第一版本信息和当前版本信息确定是否对转发设备中的配置数据进行更新，在确定需要更新时，执行步骤2033，在确定不需要更新时，执行步骤2034。

本申请实施例中，版本信息可以为版本号。如果第一配置数据的第一版本号比当前版本号高一个等级，那么判断为需要更新；如果第一配置数据的第一版本号比当前版本号低，或第一配置数据的第一版本号与当前版本号相同，或第一配置数据的第一版本号比当前版本号高一个等级以上，那么判断为不需要更新。

步骤2033、基于第一配置数据的解析结果更新转发设备上对应的配置数据，执行步骤2035。

本申请步骤中，对增量下发模式下发的第一配置数据进行解析，得到操作信息和表项数据。然后可以基于解析到的第一配置数据的表项数据和操作信息将第一配置数据配置到转发设备上，以更新转发设备上对应的配置数据。例如操作信息为修改，那么转发设备基于该第一配置数据的表项数据修改转发设备上与该第一配置数据对应的表项数据；如果操作信息为删除，那么删除转发设备上与该第一配置数据对应的配置数据；如果操作信息为添加，那么将该第一配置数据添加到转发设备上。

步骤2034、将下一条第一配置数据的第一版本信息与当前版本信息进行对比。

步骤2035、判断转发设备上配置数据的更新是否更新成功。具体而言，转发设备中对应的配置数据在完成更新之后，转发设备自动生成更新成功或更新失败的响应消息。

步骤204、基于转发设备中配置数据的更新结果更新缓存中对应的配置数据。

结合图3所示，对步骤204进行详细说明。

在更新成功时，转发设备基于第一配置数据更新缓存中对应的配置数据，从而保证每次下发配置数据之后，转发设备和缓存中存储的配置数据都保持一致，保证配置数据的正确性。

在更新完成之后，转发设备将更新成功的结果写入转发设备的回复队列。

并且，在确定为转发设备上的配置数据更新成功，以及确定为不需要更新时，读取下一条第一配置数据的第一版本信息，并判断是否需要更新(图3中的步骤2034)，重复上述更新的步骤。

步骤2041、在转发设备上的配置数据更新失败时，将更新失败的结果写入回复队列。

重复上述步骤，直至所有的第一配置数据都完成对比和更新，然后将更新结果写入回复队列，更新结果可以包括，更新成功的第一配置数据为哪些，将第一配置数据从哪个版本更新到了哪个版本，更新失败的第一配置数据为哪些等。

在本申请的增量下发模式下，转发设备通过对比第一配置数据的版本信息和缓存中存储的当前版本信息，仅更新转发设备和缓存中的高于当前版本信息一个等级的配置数据，从而能够保证多次下发的配置数据的幂等性和准确性，提高增量下发模式下的安全性，避免数据的重复下发导致的下发错误。

步骤205、基于全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新转发设备上对应的配置数据。

如图3所示，本申请步骤205可以包括下述步骤：

步骤2051、将缓存中存储的全部配置数据的状态分别标记为第二标记。

其中，第二标记可以为例如未下发。步骤2052、对接收到的第二配置数据进行解析，得到第二配置数据的表项数据，根据解析结果将第二配置数据添加到转发设备中。

步骤2053、判断转发设备中的配置数据是否更新成功。

本申请步骤中，由于全量下发模式下发的第二配置数据的默认操作信息是添加，不会修改也不会删除，因而本步骤中对第二配置数据进行解析，仅需得到表项数据，并且第二配置数据配置到转发设备，也就是将第二配置数据添加到转发设备中。

步骤2054、在转发设备中的配置数据更新成功时，将缓存中存储的对应的配置数据的状态标记为第一标记。

本申请步骤中，将缓存中更新成功的配置数据标记为与原来的标记即第二标记不同的标记，例如第一标记，或者也可以标记为已下发，从而便于根据标记的不同确定未更新的配置数据，即未被标记为第一标记的配置数据，并将更新成功的结果写入回复队列。

在增量下发模式下缓存中的配置数据完成更新时，会被打上已下发标记，而管控系统以全量下发模式下发配置数据时，缓存中的配置数据并未清空，而是存在以增量下发模式下发的配置数据的，在全量模式下发配置数据之后，为了识别缓存中的哪些数据是本次全量下发模式下发的，并保证缓存和转发设备中的配置数据的一致性，需要在更新完成之后对比配置数据的标记，因而，在全量下发模式开始，将缓存中的配置数据标记为未下发。在增量下发模式失败时会触发全量下发模式，本申请中，通过对比第二配置数据和缓存中存储的配置数据的差异，并通过覆盖的方式对转发设备和缓存中的数据进行更新，即将第二配置数据全部配置到缓存中，通过对更新前和更新后的配置数据做标记，能够确定和删除转发设备和缓存中未更新的配置数据，从而保证整体配置数据的一致性，在用户无感知不丢包的情况下完成配置数据的更新。

而且，增量下发模式与全量下发模式相结合，使增量下发更稳定。

步骤2055、在转发设备中的配置数据更新失败时，将更新失败的结果写入回复队列。

在转发设备将第二配置数据配置到转发设备之后，基于转发设备生成的响应消息，能够确定更新成功还是失败，无论更新成功还是更新失败，都将更新结果写入回复队列发送给服务器，以便服务器根据更新结果确定配置数据的下发模式，例如当在回复队列中的更新结果为更新失败时，触发服务器以全量下发模式下发配置数据。

步骤2056、判断接收的全部第二配置数据是否都已完成更新，在第二配置数据全部更新结束时，执行步骤2057，在第二配置数据未全部更新结束时，执行步骤2052。

步骤2057、删除缓存中未标记为第一标记的配置数据，及在转发设备中的与未标记为已下发的配置数据相对应配置数据。

例如，服务器下发的第二配置数据为1，2，4，缓存中存储的配置数据为1，2，3，配置数据1，2和3已被标记为已下发，那么转发设备首先会将配置数据1，2和3标记为未下发，然后基于配置数据1，2和4对转发设备中的配置数据进行更新，也就是说基于第二配置数据1更新缓存中存储的配置数据1，基于第二配置数据2更新缓存中存储的配置数据2，并将第二配置数据4添加到缓存中进行存储，在更新成功的情况下，将缓存中对应的更新成功的配置数据1、2和4标记为已下发，那么此时只有配置数据3未标记为已下发，因而将缓存中的配置数据3删除，并删除转发设备中对应的配置数据3，从而保证缓存中的配置数据、转发设备中的配置数据与下发的配置数据保持稳定一致，保证幂等性，避免用户数据出现断流。

步骤2058、将转发设备中更新成功的结果写入回复队列。

与第一配置数据的更新结果相同，将第二配置数据的更新结果写入回复队列。

步骤2059、读取回复队列中的更新结果，将第一配置数据或第二配置数据的更新结果发送给服务器。

本发明提出的虚拟网络环境下的数据的更新方法，是将增量下发模式和全量下发模式相结合的一种方案，通过在转发设备的中间件上增设缓存，来存储基于服务器每次下发的配置数据进行更新之后的最终配置数据。在增量下发模式下，将每一次配置数据的改变都同步在缓存中，同时提供保证配置数据的正确性的版本管理，通过对比本次增量下发的配置数据的版本信息和缓存中存储的当前版本信息，来判断是否需要更新转发设备中的配置数据；在判断不需要更新的情况下对于重复的请求不予重复更新，仅回复更新成功的响应，从而对增量下发模式下多线程的多次数据请求实现幂等性，提高增量下发的安全性和稳定性，保证配置数据下发正确；而且在自定义频繁的虚拟网络中，可以以较小的代码来更新配置数据，满足网络相关表项频繁变更的需求。当发生异常导致增量下发模式下发失败时，通过全量下发来保证整体配置数据的一致性，在全量下发配置数据时，并不去清空转发设备上的配置数据，而是通过对比全量下发的配置数据和缓存中的配置数据的差异，通过覆盖操作的方式基于进行配置的配置数据对转发设备和缓存中的数据进行更新，对未进行配置的配置数据进行删除，从而在用户无感知不丢包不断流的情况下完成配置。

下面结合图1B所示模块图对图1A所示的数据的更新方法进行进一步说明。

数据接收模块11接收服务器下发的配置数据，并对配置数据进行解析，得到配置数据的下发模式标识，基于下发模式标识数据接收模块11判断接收到的配置数据为增量下发模式下发的第一配置数据还是全量模式下发的第二配置数据，并将第一配置数据或第二配置数据发送到接收队列中。处理模块11从接收队列中获取配置数据，对于第一配置数据，处理模块11解析该第一配置数据得到其第一版本信息，并通过版本管理模块15获取当前版本信息，然后将第一版本信息与当前版本信息进行比对，当且仅当第一版本信息比当前版本信息稿一个等级时，处理模块12判断为转发设备中的配置数据需要更新。这种情况下，处理模块12对第一配置数据进行解析，得到第一配置数据的操作信息和表项数据，然后基于解析结果将第一配置数据配置到转发设备上，即更新转发设备上对应的配置数据。如果处理模块12判断为转发设备中的配置数据不需要更新，则对下一条第一配置数据进行上述版本信息的判断。在数据更新完成之后，转发设备自动生成更新成功或更新失败的响应，处理模块12将更新结果写入回复队列。并且，在更新成功的情况下，处理模块12基于第一配置数据更新缓存模块14中的配置数据，并将缓存模块14中的数据都标记为已下发。

对于第二配置数据，处理模块12将缓存模块14中存储的全部配置数据都打上未下发的标记；然后对第二配置数据进行解析，将解析得到的表项数据添加、即配置到转发设备中，并将缓存模块14中更新成功的配置数据的状态标记为已下发，在第二配置数据更新完毕时，删除缓存模块14中未标记为已下发的配置数据，以及转发设备中的与未标记为已下发的配置数据相对应的配置数据。并且，将更新的结果写入回复队列。回复模块13从回复队列中获取更新的结果，并将更新结果进行编程等处理后，返回给管控系统。

与本申请数据的更新方法的实施例相对应，本申请还提供了数据的更新装置及设备的实施例。

本申请数据的更新装置的实施例可以应用在转发设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请数据的更新装置所在设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，图4中不再一一示出。

参见图5，为本申请数据的更新装置的一个实施例框图，该装置可以应用在转发设备上，该装置包括：接收单元510和第一更新单元520。

其中，接收单元510，用于接收服务器下发的配置数据；

第一更新单元520，用于基于所述配置数据的下发模式，及缓存中存储的配置数据和当前版本信息，对转发设备中的配置数据进行更新；其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

在一个可选的实现方式中，该装置还可以包括(图5中未示出)：

提取单元，用于提取所述配置数据中的下发模式标识；

判断单元，用于基于所述下发模式标识判断所述配置数据的下发模式，所述下发模式包括增量下发模式和全量下发模式。

在一个可选的实现方式中，第一更新单元520可以包括(图5中未示出)：

第一更新子单元，用于在所述配置数据的下发模式为增量下发模式时，基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备上对应的配置数据；

第二更新子单元，用于在所述配置数据的下发模式为全量下发模式时，基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据。

在一个可选的实现方式中，第一更新单元520可以包括(图5中未示出)：

第一读取模块，用于读取所述增量下发模式下发的第一配置数据的第一版本信息；

第二读取模块，用于读取所述缓存中存储的当前版本信息；

确定模块，用于在第一版本信息高于当前版本信息一个等级时，确定需要更新；

第一解析模块，用于解析需要更新的第一配置数据，得到操作信息和表项数据；

第一更新模块，用于基于操作信息和表项信息更新所述转发设备中对应的配置数据。

在另一个可选的实现方式中：第一更新子单元520还可以包括(图5中未示出)：

第二更新模块，用于在转发设备中对应的配置数据更新成功时，基于所述操作信息和表项数据更新所述缓存中对应的配置数据。

在一个可选的实现方式中，第二更新子单元包括(图5中未示出)：

第二解析模块，用于解析所述第二配置数据，基于解析的结果更新所述转发设备上对应的配置数据；

第三更新模块，用于在转发设备中对应的配置数据更新成功时，基于第二配置数据中的表项数据更新缓存中对应的配置数据；

第一标记模块，用于将所述缓存中的更新成功的配置数据分别标记为与原来的标记不同的第一标记；

删除模块，用于在所述第二配置数据更新结束时，删除所述缓存中未被标记为第一标记的配置数据，并删除所述转发设备中对应的配置数据。

在另一个可选的实现方式中：装置还可以包括(图5中未示出)：

发送单元，用于将所述配置数据的更新结果发送给所述服务器，所述更新结果包括更新失败结果和更新成功结果，所述第一配置数据的更新失败结果用于触发所述服务器以全量下发模式下发第二配置数据。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

由上述实施例可见，转发设备通过在中间件中增设缓存，来存储服务器每次下发配置数据之后的最终配置数据和当前版本信息，在增量下发模式下，将每一次配置数据的改变都同步在缓存中，同时提供保证配置数据的正确性的版本管理，保证对多次数据请求实现幂等性，提高增量下发的安全性，保证配置数据下发正确；当增量下发模式下发失败时，通过全量下发来保证整体配置数据的一致性，在全量下发配置数据时，并不去清空转发设备上的配置数据，通过对比全量下发的配置数据和缓存中的配置数据的差异，通过覆盖操作的方式对转发设备和缓存中的数据进行更新，对未配置的配置数据进行删除，从而在用户无感知不丢包的情况下完成配置。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (15)

1.一种数据的更新方法，应用在转发设备上，其特征在于，包括：

接收服务器下发的配置数据，提取所述配置数据中的下发模式标识；

基于所述下发模式标识判断所述配置数据的下发模式，所述下发模式包括增量下发模式和全量下发模式；

在所述配置数据的下发模式为增量下发模式时，基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备上对应的配置数据；

在所述配置数据的下发模式为全量下发模式时，基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据；

其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

2.根据权利要求1所述的方法，其特征在于，所述基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备中对应的配置数据，包括：

读取所述增量下发模式下发的第一配置数据的第一版本信息；

读取所述缓存中存储的当前版本信息；

在所述第一版本信息高于所述当前版本信息一个等级时，确定需要更新；

解析需要更新的第一配置数据，得到操作信息和表项数据；

基于所述操作信息和所述表项数据更新所述转发设备中对应的配置数据。

3.根据权利要求2所述的方法，其特征在于，所述基于所述操作信息和所述表项数据更新所述转发设备中对应的配置数据之后，所述方法还包括：

在所述转发设备中对应的配置数据更新成功时，基于所述操作信息和表项数据更新所述缓存中对应的配置数据。

4.根据权利要求1所述的方法，其特征在于，所述基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据，包括：

解析所述第二配置数据，基于解析的结果更新所述转发设备上对应的配置数据；

在所述转发设备中对应的配置数据更新成功时，基于所述第二配置数据中的表项数据更新所述缓存中对应的配置数据；

将所述缓存中的更新成功的配置数据分别标记为与原来的标记不同的第一标记；

在所述缓存中对应的第二配置数据更新结束时，删除所述缓存中未被标记为所述第一标记的配置数据，并删除所述转发设备中对应的配置数据。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

将所述配置数据的更新结果发送给所述服务器，所述更新结果包括更新失败结果和更新成功结果，所述第一配置数据的更新失败结果用于触发所述服务器以全量下发模式下发第二配置数据。

6.一种数据的更新装置，应用在转发设备上，其特征在于，包括：

接收单元，用于接收服务器下发的配置数据；

提取单元，用于提取所述配置数据中的下发模式标识；

判断单元，用于基于所述下发模式标识判断所述配置数据的下发模式，所述下发模式包括增量下发模式和全量下发模式；

第一更新单元，用于在所述配置数据的下发模式为增量下发模式时，基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备上对应的配置数据；在所述配置数据的下发模式为全量下发模式时，基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据；其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

7.根据权利要求6所述的装置，其特征在于，所述第一更新单元包括：

第一读取模块，用于读取所述增量下发模式下发的第一配置数据的第一版本信息；

第二读取模块，用于读取所述缓存中存储的当前版本信息；

确定模块，用于在所述第一版本信息高于所述当前版本信息一个等级时，确定需要更新；

第一解析模块，用于解析需要更新的第一配置数据，得到操作信息和表项数据；

第一更新模块，用于基于所述操作信息和所述表项数据更新所述转发设备中对应的配置数据。

8.根据权利要求7所述的装置，其特征在于，所述第一更新单元还包括：

第二更新模块，用于在所述转发设备中对应的配置数据更新成功时，基于所述操作信息和表项数据更新所述缓存中对应的配置数据。

9.根据权利要求6所述的装置，其特征在于，所述第一更新单元包括：

第二解析模块，用于解析所述第二配置数据，基于解析的结果更新所述转发设备上对应的配置数据；

第三更新模块，用于在所述转发设备中对应的配置数据更新成功时，基于所述第二配置数据中的表项数据更新所述缓存中对应的配置数据；

第一标记模块，用于将所述缓存中的更新成功的配置数据分别标记为与原来的标记不同的第一标记；

删除模块，用于在所述第二配置数据更新结束时，删除所述缓存中未被标记为所述第一标记的配置数据，并删除所述转发设备中对应的配置数据。

10.根据权利要求6-9任一项所述的装置，其特征在于，所述装置还包括：

发送单元，用于将所述配置数据的更新结果发送给所述服务器，所述更新结果包括更新失败结果和更新成功结果，所述第一配置数据的更新失败结果用于触发所述服务器以全量下发模式下发第二配置数据。

11.一种转发设备，其特征在于，包括：

数据接收模块，用于接收服务器下发的配置数据；

缓存模块，用于缓存基于所述服务器上一次下发的配置数据进行更新之后得到的配置数据；

版本管理模块，用于存储所述转发设备存储的配置数据的当前版本信息；

处理模块，与所述数据接收模块、所述缓存模块及所述版本管理模块连接，用于提取所述配置数据中的下发模式标识；基于所述下发模式标识判断所述配置数据的下发模式，所述下发模式包括增量下发模式和全量下发模式；在所述配置数据的下发模式为增量下发模式时，基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备上对应的配置数据；在所述配置数据的下发模式为全量下发模式时，基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据；其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

12.根据权利要求11所述的设备，其特征在于，所述处理模块用于：

读取所述第一配置数据的第一版本信息，及所述当前版本信息；

在所述第一版本信息高于所述当前版本信息一个等级时，确定需要更新所述转发设备上的配置数据；

解析需要更新的第一配置数据，得到操作信息和表项数据；

基于所述操作信息和所述表项数据更新所述转发设备中对应的配置数据，以及在更新成功时，基于所述操作信息和表项数据更新所述缓存模块中对应的配置数据。

13.根据权利要求11所述的设备，其特征在于，所述处理模块用于：

解析所述第二配置数据，基于解析的结果更新所述转发设备上对应的配置数据；

在所述转发设备中对应的配置数据更新成功时，基于所述第二配置数据中的表项数据更新所述缓存模块中对应的配置数据；

将所述缓存模块中的更新成功的配置数据分别标记为与原来的标记不同的第一标记；

在所述第二配置数据更新结束时，删除所述缓存模块中未被标记为所述第一标记的配置数据，并删除所述转发设备中对应的配置数据。

14.根据权利要求11-13任一项所述的设备，其特征在于，还包括：

回复模块，与所述处理模块连接，用于将所述处理模块的更新结果回复给所述服务器。

15.一种数据的更新设备，其特征在于，所述设备为转发设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为：

接收服务器下发的配置数据，提取所述配置数据中的下发模式标识；

基于所述下发模式标识判断所述配置数据的下发模式，所述下发模式包括增量下发模式和全量下发模式；

在所述配置数据的下发模式为增量下发模式时，基于所述增量下发模式下发的第一配置数据的版本信息更新所述转发设备上对应的配置数据；

在所述配置数据的下发模式为全量下发模式时，基于所述全量下发模式下发的第二配置数据与缓存中存储的配置数据的差异，更新所述转发设备上对应的配置数据；

其中，所述缓存用于存储配置数据及所存储的配置数据的当前版本信息。

Images