CN109450977A - 缓存数据的推送、更新方法及装置 - Google Patents

Abstract

本说明书实施例提供一种缓存数据的推送、更新方法和装置。一方面，缓存服务端在第一数据项发生变更时，根据第一数据项的变更信息，针对第一数据项生成当前版本的增量信息，并以当前版本作为最新版本，生成包括多个连续版本的增量信息的推送增量包，向至少一个缓存客户端推送；另一方面，缓存客户端从缓存服务端接收上述推送增量包，将缓存客户端中第一数据项的当前数据的最后更新版本与多个连续版本进行比较，以确定对当前数据的更新策略。该实施方式可以提高增量信息推送的有效性。

Description

缓存数据的推送、更新方法及装置

技术领域

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及通过计算机对缓存数据进行推送的方法和装置，以及通过计算机对缓存数据进行更新的方法和装置。

背景技术

在一些大型分布式软件项目中，对于一些需要频繁使用的配置类参数(例如用系统功能开关等)，需要从数据库或指定文件中读取。对于集群环境而言，每个集群机器都需要加载这份配置参数。各个集群机器频繁读取数据库或指定文件中的参数，就会产生数据读写压力。为了加快读取速度，对于不会频繁改变(例如不会每次都改变或者定时改变等)的配置参数，往往需要预先存储在本地的内存中，也就是本地缓存。这样，把集成了配置数据的数据库或者指定文件，并提供缓存内容的服务器看作缓存服务端，而各个从缓存服务端加载配置参数的集群机器就是缓存客户端。

在这种模式下，如果缓存服务端的数据发生变化，各个缓存客户端的数据也要随之发生变化。常规技术中，往往通过缓存服务端向各个缓存客户端广播服务端数据发生变化的消息，由缓存客户端向缓存服务端发送数据拉取请求来获取新数据。这种情况下，不管获取全量数据或增量数据，都需要缓存客户端与缓存服务端的交互，增加系统调用。为了避免这种系统调用导致增加数据处理量，在一些常规技术中，还采用推送全量或当前增量数据的方式来更新缓存客户端的数据。然而，一方面，全量推送的数据量较大，另一方面，只推送当前增量数据的情况下，如果由于网络等原因，造成分布式环境下，客户端关于缓存的版本在瞬间是不一致的，例如某客户端版本是V1，则下次推送的增量数据(如V3到V4增量)因为缺少V2V3增量，可能无法在客户端使用。

因此，希望能有改进的方案，使得缓存客户端对缓存服务端推送的数据有更高的接受率，从而提高缓存数据的有效性。

发明内容

本说明书一个或多个实施例描述了一种缓存数据的推送方法和装置，以及缓存数据的更新方法和装置，分别用于缓存服务端向缓存客户端推送数据，以及缓存客户端根据缓存服务端推送的数据选择性更新本地数据。通过缓存服务端向缓存客户端推送数据时，冗余多个版本的增量数据，以供缓存客户端对比和选择，可以提高缓存客户端对缓存服务端推送的数据的接受率，从而提高缓存数据推送、接收的有效性。

根据第一方面，提供了一种缓存数据的推送方法，用于缓存服务端，所述方法包括：响应于第一数据项发生变更，根据所述第一数据项的变更信息，针对所述第一数据项生成当前版本的增量信息；生成推送增量包，所述推送增量包包括多个连续版本的增量信息，所述当前版本为所述多个连续版本中的最新版本；向至少一个缓存客户端推送所述推送增量包，以供所述至少一个缓存客户端根据所述推送增量包确定对各个缓存客户端中与所述第一数据项对应的当前数据的更新策略。

在一个实施例中，所述当前版本具有按照所述第一数据项的变更次序确定的当前版本标识。

可选地，所述当前版本标识通过在所述第一数据项的前一版本的增量数据的版本标识上增加预定值生成。

在一个实施例中，所述生成推送增量包包括：获取增量信息的预定推送版本数；按照所述预定推送版本数，从所述当前版本开始倒序选取所述预定推送版本数的各个版本的增量信息；根据所选取的增量信息生成推送增量包。

在一个实施例中，所述预定推送版本数与所述第一数据项的变更频率正相关。

在一个实施例中，所述至少一个缓存客户端包括第一缓存客户端，所述方法还包括：接收所述第一缓存客户端用于获取增量信息的数据请求，所述数据请求由所述第一缓存客户端在以下情况下，根据所述更新策略发出：所述当前数据的最后更新版本，早于所述推送增量包中增量信息的最早版本的前一个版本，所述最后更新版本与所述当前数据最后一次更新时所依据的增量数据版本相一致；根据所述数据请求向所述第一缓存客户端发送所述最后更新版本与所述当前版本之间的增量信息。

根据第二方面，提供一种缓存数据的更新方法，用于缓存客户端，所述方法包括：接收缓存服务端针对第一数据项推送的推送增量包，其中，所述推送增量包包括多个连续版本的增量信息；将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较，其中，所述最后更新版本与所述当前数据最后一次更新时所依据的增量信息的版本一致；根据比较结果确定对所述当前数据的更新策略。

根据一种实现方式，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：对比所述多个连续版本中的最早版本的前一个版本与所述最后更新版本，所述最早版本是所述多个连续版本中最早生成的版本；以及

根据比较结果确定对所述当前数据的更新策略包括：在所述最后更新版本早于所述最早版本的前一个版本的情况下，向所述缓存服务端发送数据请求，以请求所述最后更新版本之后的各个版本的增量信息。

根据另一种实现方式，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：对比所述多个连续版本中的最新版本与所述最后更新版本，所述最新版本是所述多个连续版本中最晚生成的版本；以及

根据比较结果确定对所述当前数据的更新策略包括：在所述最后更新版本不早于所述最新版本的情况下，确定无需更新所述当前数据。

根据又一种实现方式，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：检测所述最后更新版本是否落入以下版本范围：所述多个连续版本中的最早版本的前一个版本与所述多个连续版本中的最新版本的前一个版本之间；以及

根据比较结果确定对所述当前数据的更新策略包括：在落入的情况下，用所述最后更新版本的后一个版本至所述最新版本的增量信息更新所述当前数据。

根据第三方面，提供一种缓存数据的推送装置，设置于缓存服务端，所述装置包括：第一生成单元，配置为响应于第一数据项发生变更，根据所述第一数据项的变更信息，针对所述第一数据项生成当前版本的增量信息；第二生成单元，配置为生成推送增量包，所述推送增量包包括多个连续版本的增量信息，所述当前版本为所述多个连续版本中的最新版本；发送单元，配置为向至少一个缓存客户端推送所述推送增量包，以供所述至少一个缓存客户端根据所述推送增量包确定对各个缓存客户端中与所述第一数据项对应的当前数据的更新策略。

根据第四方面，提供一种缓存数据的更新装置，设置于缓存客户端，所述装置包括：接收单元，配置为接收缓存服务端针对第一数据项推送的推送增量包，其中，所述推送增量包包括多个连续版本的增量信息；比较单元，配置为将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较，其中，所述最后更新版本与所述当前数据最后一次更新时所依据的增量信息的版本一致；确定单元，配置为根据比较结果确定对所述当前数据的更新策略。

根据第五方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面或第二方面的方法。

根据第六方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面或第二方面的方法。

通过本说明书实施例提供的缓存数据的推送、更新方法和装置，一方面，缓存服务端在第一数据项发生变更时，根据第一数据项的变更信息，针对第一数据项生成当前版本的增量信息，并以当前版本作为最新版本，生成包括多个连续版本的增量信息的推送增量包，向至少一个缓存客户端推送。另一方面，缓存客户端从缓存服务端接收上述推送增量包，将缓存客户端中第一数据项的当前数据的最后更新版本与多个连续版本进行比较，以确定对当前数据的更新策略。由于所推送的版本中有多个连续版本的增量信息的冗余，可以提高缓存客户端对推送增量包的接受率，从而提高增量信息推送的有效性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出本说明书披露的一个实施例的实施场景示意图；

图2示出上述实施场景中常规技术的一个执行流程示意图；

图3示出根据一个实施例的缓存数据的推送方法流程图；

图4示出根据一个实施例的缓存数据的更新方法流程图；

图5示出根据一个实施例的缓存数据的推送装置的示意性框图；

图6示出根据一个实施例的缓存数据的更新装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1示出了本说明书披露的一个实施例的实施场景的示意。如图1所示，本说明书实施例的缓存数据的推送方法及装置适用于图1中的缓存服务端，其中缓存服务端可以是可用于存储数据的设备或设备集群，也可以是设备或设备集群中的指定模块等。例如缓存服务端可以是分布式存储系统、数据库、包含指定文件的存储装置等等。可以理解，缓存客户端是和缓存服务端是相对的概念，由多个缓存客户端都可以从缓存服务端获取数据的架构而产生的。缓存客户端本身还可以是为各种应用客户端提供支持的服务器(如支付服务器等)。缓存客户端可以从缓存服务端获取自身需要的配置数据，例如支付业务需要的目前系统支持的银行列表等等。在缓存客户端是软件开发过程中的开发客户端的情况下，上述配置数据还可以是开发客户端需要的配置参数、功能模块等。

请参考图2。在该实施场景中，缓存服务器的某个数据项(如支持支付的银行名称)，这里称为数据项1，发生数据变更时，数据项1的数据版本升高(如从V99变成V100)。缓存服务器可以记录数据项1变更的增量信息。缓存服务端在记录增量信息时，可以将增量信息的当前版本与数据项1变更后的版本(如V100)相对应，例如使用同样的版本标识V100。数据项1发生变更后，缓存服务端可以将增量信息推送至缓存客户端。其中，缓存客户端可以有多个，图2中作为示例，仅仅示出其中的一个。在一个实现中，缓存客户端收到数据项1的增量信息后，可以通过本地数据项1的版本判断自身是否需要更新，如果需要(例如版本低于所推送的增量信息对应的版本)，就根据所收到的增量信息更新该数据项1。更新完成后，缓存客户端还可以更新本地数据项1的数据版本为新的版本(如通过版本标识V100记录的版本)。

常规技术中，缓存服务端在推送增量信息时，往往推送当前版本的一条增量信息。然而，实际中，由于设备和网络等各方面的可能原因，各个缓存客户端的当前数据版本可能是不一致的。例如，缓存客户端1中数据项1的当前数据版本为V97，缓存客户端2中数据项1的当前数据版本为V98，缓存客户端3中数据项1的当前数据版本为V99……当接收到版本V100的增量信息时，缓存客户端1、2、3均需要更新。然而，只有缓存客户端3可以与缓存服务端的数据项1进行相同的变更。由于每次缓存服务端的每次更新都是在前一次更新的基础上进行的，为了避免错乱，缓存客户端也需要按照增量信息的版本顺序进行更新。如果缓存客户端1和缓存客户端2也需要更新，则需向缓存服务端发送数据请求，先依次按照版本V98、V99的增量信息进行更新，然后才能按照版本V100的增量信息进行更新。这种情况下，产生系统调用，同时增加缓存服务端的数据压力。

本说明书提供的实施例中，缓存服务端向缓存客户端推送增量信息时，可以有一定数量的冗余。换句话说，可以一次推送多个连续版本的增量信息。例如，当缓存服务端的数据项1变更后的版本为V100，可以同时推送通过V97、V98、V99、V100标记的增量数据。这样，可以由缓存客户端根据自身情况确定更新策略，从而在各个缓存客户端数据版本不一致的情况下，可以有更多的缓存客户端可以顺利更新自身的数据项1。如上述例子中，针对数据项1，缓存客户端1中的数据版本可以依次按照：V98、V99、V100的增量信息进行更新，缓存客户端2中的数据版本可以依次按照：V99、V100的增量信息进行更新，缓存客户端3中的数据版本可以依次按照：V100的增量信息进行更新。如此，可以大大提高缓存客户对所推送的增量数据的接受率，从而可以提高缓存数据推送的有效性。

下面详细描述以上实施场景的具体执行过程。

图3示出根据一个实施例的缓存数据的推送方法流程图。该方法的执行主体例如是图1所示的缓存服务端等。其可以是任何具有计算、处理能力的系统、设备、装置、平台或服务器。

如图3示，该方法包括以下步骤：步骤31，响应于第一数据项发生变更，根据第一数据项的变更信息，针对第一数据项生成当前版本的增量信息；步骤32，生成推送增量包，推送增量包包括多个连续版本的增量信息，当前版本为多个连续版本中的最新版本；步骤33，向至少一个缓存客户端推送上述推送增量包，以供至少一个缓存客户端根据推送增量包确定对各个缓存客户端中与第一数据项对应的当前数据的更新策略。

首先，在步骤31，响应于第一数据项发生变更，根据第一数据项的变更信息，针对第一数据项生成当前版本的增量信息。可以理解，针对某一个数据项，为了表述方便，我们称之为“第一数据项”。这里的“第一”表示某一、任一。一个数据项，也可以理解为一项数据。例如，付款可以选择的银行等等。

一个数据项还可以包括多条数据。请参考表1，是一个关于付款可选银行的数据项的示例。其中，开关状态可以表示是否允许展示给用户的状态，或者是否可以连接的状态。如表1所示，当前版本的该数据项中包括8条数据。

表1支付银行列表

数据的变更，通常可以包括增加、删除、修改中的至少一项。在一个数据项可包括多条数据(在某个时刻可能只包括一条数据)的情况下，数据项的变更，可以是删除或修改其中的一条或多条数据，也可以是在原有数据的基础上增加一条或多条数据。例如，针对表1示出的数据项，可以发生诸如：删除第5至第8条数据、修改第3条数据、增加第9至12条数据等等之类的变更。数据项的变更可以响应于用户的操作进行，也可以响应于定时装置的触发进行，还可以是响应于其他的各种合理状况进行，本说明书实施例对此不作限定。针对一个数据项的一次变更所产生的信息，可以称为变更信息。

如前所述，对于上述第一数据项而言，每进行一次变更，可以确定对应的数据版本。该数据版本可以通过该第一数据项的变更次序来确定。实践中，为了便于识别，每个数据版本可以通过预定规则确定相应的数据标识来表示。数据版本用于缓存服务端和缓存客户端识别版本生成的先后顺序。上述预定规则可以是预先确定的各种规则。例如，版本标识可以包含数值，预定规则可以是：每一次变更对应的版本标识中所包含的数值可以在前一版本的版本标识基础上增加预定值(如1)。再例如，版本标识可以包含时间序列，预定规则可以是：将每次变更时的时间戳作为版本标识，如20180920180653。又例如，版本标识可以包含英文字母，预定规则可以是：版本标识按照英文字母顺序排列，如依次取VA、VB、VC等等。在一个实施例中，原始数据版本标识可以预先确定。当前一次变更产生的数据版本是当前版本。

增量，也称为改变量。顾名思义，增量信息，也就是变更信息。在这里，当前版本的增量信息，可以根据当前一次数据变更的变更信息生成。例如，当前一次变更为修改若干条数据，那么变更信息至少可以包括修改数据所在的位置(例如第5至8条数据)、修改内容等信息。其中，修改信息至少可以包括修改后的内容，也可以包括修改前的内容。一条变更信息可以针对某个数据项的一次变更。因此，对每一次变更，可以生成一条增量信息。为了区分，增量信息也可以有对应的数据版本。当前次变更生成当前版本的增量信息。第一数据项的增量信息的数据版本可以和变更后的第一数据项的数据版本一致，也可以不一致。在版本不一致的情况下，各个增量信息的数据版本与第一数据项的数据版本存在一定对应关系。在一些实施例中，第一数据项的当前增量信息的当前版本，可以与第一数据项变更后的当前版本相对应，并具有一致的版本标识。在此不再赘述。

接着，通过步骤32，生成推送增量包。可以理解，推送增量包中可以包括多个版本的增量信息，以作为冗余增量。为了使推送增量包中包括最新多条的增量信息，所选取的增量信息对应的各个版本需要连续，并且包含当前版本在内。进一步地，当前版本作为最新版本。也就是说，这多个连续版本到当前版本结束。

冗余增量的多少，即待推送增量信息的预定推送版本数，可以预先确定。在一个实施例中，预定推送版本数可以与相应数据项的变更频率正相关。换句话说，对于第一数据项，如果其变更频率较低，则预定推送版本数可以相对比较少。比如：第一数据项平均3天更新一次，假设变更频率以次/天为单位计算，该第一数据项的变更频率为(1/3)次/天，预定推送版本数可以是2个；第一数据项平均1天更新一次，该第一数据项的变更频率为1次/天，预定推送版本数可以是6个；等等。其中，第一数据项的变更频率可以按照“(第一数据项的第一个版本到当前版本的总版本数)/经历的总时间”计算，也可以按照“预定时间段内变更的总次数/预定时间段”计算，还可以按照其他合理的方式计算，本说明书实施例对此不作限定。

根据一个实现方式，可以先获取增量信息的预定推送版本数(如5)，然后按照预定推送版本数，从当前版本开始倒序选取预定推送版本数个版本(如5个版本)的增量信息，然后将所选取的增量信息打包，生成推送增量包。其中，从当前版本开始倒序选取预定推送版本数的各个版本的增量信息时，可以按照版本标识倒序选取相应的增量信息，也可以将各个版本的增量信息按顺序排列，直接按照倒序选取预定推送版本数的条数(如5条)的增量信息即可。

根据另一个实施方式，在获取增量信息的预定推送版本数后，还可以先按照版本标识的排列顺序，倒序获取包括当前版本在内的多个版本(如5个版本)的版本标识，再进一步获取各个版本标识所对应的增量信息，生成推送增量包。

如此，假如增量信息的当前版本为V100，推送增量包中可以包括V98、V99、V100这几个版本的增量信息作为冗余。

然后，在步骤33，向至少一个缓存客户端推送上述推送增量包。可以理解，缓存服务端可以将以上针对第一数据项生成的推送增量包广播给各个缓存客户端。在一个实现中，可以向所有的缓存客户端都发送上述推送增量包。在另一个实现中，缓存服务端也可以预先记录有哪些缓存客户端需要该第一数据项，从而，只向需要该第一数据项的这些缓存客户端发送上述推送增量包。

对于每个缓存客户端而言，其可以根据推送增量包确定缓存客户端中与第一数据项对应的当前数据的更新策略。进一步说，更新策略可以包括更新与第一数据项对应的当前数据，或者不更新与第一数据项对应的当前数据。在更新的情况下，更新策略还可以包括选择按照哪些增量信息更新与第一数据项对应的当前数据。其中，缓存客户端中与第一数据项对应的当前数据，是缓存客户端直接从缓存服务端获取的原始数据，也可以是在原始数据的基础上按照以往收到的推送增量包更新过的数据。可以理解，缓存客户端中与第一数据项对应的当前数据可以具有最后更新版本。该最后更新版本可能是其从缓存服务端获取的原始数据的数据版本，也可能是与最近一次更新时所依据的增量信息的版本对应一致的版本。缓存客户端对当前数据的更新可以通过图4示出的适用于缓存客户端的缓存数据的更新方法的一个实施例完成，在此不再赘述。

将缓存客户端中的任一个成为“第一缓存客户端”，根据一个可能的设计，如果第一客户端中与第一数据项相对应的当前数据的最后更新版本，早于推送增量包中增量信息的最早版本的前一个版本，该第一客户端还可以向缓存服务端发送数据请求，以请求最后更新版本与当前版本之间的部分或全部增量信息。其中，上述最后更新版本可以是，缓存客户端中与第一数据项对应的当前数据最后一次更新时所依据的增量数据版本。举例而言，针对第一数据项，假设推送增量包中的增量信息对应的多个版本包括V98、V99、V100，某个缓存客户端上存储的该第一数据项的最后更新版本是V95，低于增量信息的最早版本的前一个版本V97，无法更新V98、V99、V100。此时，该缓存客户端可以向缓存服务端发送用于获取增量信息的数据请求。该数据请求可以针对版本V96～V97的增量信息，也可以针对V96～V100的信息。

此时，图3示出的方法还可以包括以下步骤：

接收第一缓存客户端用于获取增量信息的数据请求；

根据数据请求向第一缓存客户端发送最后更新版本与当前版本之间的增量信息。

接着，请参阅图4。图4示出根据一个实施例的缓存数据的更新方法流程图。该方法的执行主体例如是图1所示的缓存客户端等。其可以是任何具有计算、处理能力的系统、设备、装置、平台或服务器。

如图4示，该方法包括以下步骤：步骤41，接收缓存服务端推送的针对第一数据项的推送增量包，其中，推送增量包包括多个连续版本的增量数据；步骤42，将该多个连续版本与第一数据项的当前数据的最后更新版本进行比较，其中，最后更新版本与当前数据最后一次更新时所依据的增量数据版本一致；步骤43，根据比较结果确定对当前数据的更新策略。

首先，在步骤41，接收缓存服务端推送的针对第一数据项的推送增量包。其中，多个连续版本，就是几次连续的变更发生时生成的增量信息。推送增量包中可以包括多个连续版本的增量信息，以作为冗余增量。冗余增量的多少，即待推送增量信息的预定推送版本数，可以预先确定。在一个实施例中，预定推送版本数可以与第一数据项的变更频率正相关。

在一个实施例中，每个版本的增量信息可以通过相应的版本标识来表示。该版本标识可以由缓存服务端的第一数据项进行变更的变更次序确定。例如，第一数据项的原始版本的版本标识为V0，第一次变更后版本标识为V1，以此类推。版本标识可以按照预定规则生成。

缓存服务器中的第一数据项每发生一次变更，就可以向缓存客户端发送一次推送增量包。在所发送的缓存增量包中包括当前次变更生成的当前版本的增量信息。例如，当前次变更生成当前版本V100的增量信息，推送增量包中可以包括多个连续版本V98、V99、V100的增量信息。

接着，通过步骤42，将该多个连续版本与缓存客户端中第一数据项的当前数据的最后更新版本进行比较。其中，该最后更新版本与缓存客户端对第一数据项最近一次更新时所依据的增量信息的版本相一致。例如，具有相同的版本标识。可以理解，在缓存客户端，第一数据项的更新可以按照增量数据的版本排序进行的，即每次更新所依据的增量信息的版本，须是前一次更新所依据的增量信息版本(如V99)的后一个版本(如V100)。如此，可以避免一些情况下的据变更产生混乱。

根据一个可能的设计，可以先对缓存客户端中的最后更新版本是否早于上述多个连续版本中的最新版本进行检测。容易理解，该最新版本就是缓存服务端发送的上述增量数据包中，按照第一数据项变更次序最晚确定的增量信息的版本。如果缓存客户端中的最后更新版本早于该最新版本，则缓存客户端中的第一数据项至少没有根据该最新版本更新过，从而需要进行更新。如果缓存客户端中的最后更新版本与该最新版本一致或晚于该最新版本，即不早于该最新版本，则缓存客户端中的第一数据项至少根据该最新版本更新过(也可能根据该最新版本的后续版本更新过)。作为示例，请参考表2。假设增量数据包中的多个连续版本包括V98、V99、V100，缓存客户端中第一数据项更后更新版本为V100、V101，则缓存客户端中的最后更新版本不早于该最新版本。

表2缓存客户端更新示意

根据另一个可能的设计，还可以对比多个连续版本中的最早版本与上述最后更新版本。其中，该最早版本是多个连续版本中最早生成的版本。容易理解，如果最后更新版本早于最早版本的前一个版本，缓存客户端中第一数据项的版本与其无法连续，所以可能无法直接更新。例如表2中的最早版本是V98，在最后更新版本是V96的情况下，最后更新版本V96早于最早版本的前一个版本V97。

根据又一个可能的设计，缓存客户端还可以检测最后更新版本是否落入多个连续版本中的最早版本的前一个版本与多个连续版本中的最新版本的前一个版本之间。参考表2中的示例，最后更新版本V97、V98、V99都落入了最早版本V98的前一个版本V97与最新版本V100的前一个版本V99之间。

步骤43，根据匹配结果确定对上述当前数据的更新策略。可以理解，更新策略可以包括更新或不更新，如果更新，还可以包括选择其中部分或全部更新。

在一个实施例中，在上述最后更新版本不早于上述最新版本的情况下，可以确定当前数据的更新策略为：无需更新当前数据；

在一个实施例中，在上述最后更新版本早于上述最早版本的前一个版本的情况下，可以确定当前数据的更新策略为：向缓存服务端发送数据请求，以请求上述最后更新版本(如V96)之后的各个版本的增量信息、最后更新版本(如V96)之后且在最早版本(如V98)之前的各个版本的增量信息，或者不更新上述当前数据；

在一个实施例中，在上述最后更新版本落入多个连续版本中的最早版本的前一个版本与多个连续版本中的最新版本的前一个版本之间的情况下，可以用最后更新版本(如V97)之后至最晚版本(如V100)之间的增量信息更新当前数据。

值得说明的是，由于缓存服务端和缓存客户端相互配合，图3和图4所示出的实施例中，相关描述可以相互适应，在此不再赘述。

回顾以上过程，在缓存服务端向缓存客户端推送增量信息过程中，推送多个连续版本的增量信息，形成增量信息的冗余。通过冗余增量信息，可供缓存客户端根据自身相应数据项的版本，选择性确定是否需要更新相应数据项、在需要更新的情况下，按照哪些版本的增量信息进行更新。如此，可以提高缓存客户端对所推送的增量数据的接受率，从而，提高增量信息推送的有效性。进一步地，在需要更新的情况下，如果缓存客户端版本过低无法更新，还可以向缓存服务端发送数据请求，以从缓存服务端获取缓存客户端版本的后续版本。如此，可以使缓存客户端对相应数据项按照增量信息的版本顺序进行更新，保证缓存客户端与缓存服务端数据的同步。

根据另一方面的实施例，还提供一种缓存数据的推送装置。图5示出根据一个实施例的缓存数据的推送装置的示意性框图。如图5所示，缓存数据的推送装置500包括：第一生成单元51，配置为响应于第一数据项发生变更，根据第一数据项的变更信息，针对第一数据项生成当前版本的增量信息；第二生成单元52，配置为生成推送增量包，推送增量包包括多个连续版本的增量信息，当前版本为多个连续版本中的最新版本；发送单元53，配置为向至少一个缓存客户端推送上述推送增量包，以供至少一个缓存客户端根据推送增量包确定对各个缓存客户端中与第一数据项对应的当前数据的更新策略。

根据一个实施例，上述当前版本还可以具有按照第一数据项的变更次序确定的当前版本标识。该当前版本标识可以通过预定的规则确定。例如，版本标识可以包含数值，预定规则可以是：每一次变更对应的版本标识中所包含的数值可以在前一版本的版本标识基础上增加预定值；版本标识可以包含时间序列，预定规则可以是：将每次变更时的时间戳作为版本标识；版本标识可以包含英文字母，预定规则可以是：版本标识按照英文字母顺序排列；等等。

根据一个可能的实施例，第二生成单元52进一步可以配置为：获取增量信息的预定推送版本数；按照预定推送版本数，从当前版本开始倒序选取预定推送版本数的各个版本的增量信息；根据所选取的增量信息生成推送增量包。在一个实施例中，预定推送版本数与第一数据项的变更频率正相关。

根据一个实施方式，上述至少一个缓存客户端包括第一缓存客户端，装置500还可以包括数据请求处理单元(未示出)，配置为：

接收第一缓存客户端用于获取增量信息的数据请求，数据请求由第一缓存客户端在以下情况下，根据更新策略发出：当前数据的最后更新版本，早于推送增量包中增量信息的最早版本的前一个版本，最后更新版本与当前数据最后一次更新时所依据的增量数据版本相一致；根据数据请求向第一缓存客户端发送最后更新版本与当前版本之间的增量信息。

值得说明的是，图5所示的装置500是与图3示出的方法实施例相对应的装置实施例，图3示出的方法实施例中的相应描述同样适用于装置500，在此不再赘述。

根据再一方面的实施例，还提供一种缓存数据的更新装置。图6示出根据一个实施例的缓存数据的更新装置的示意性框图。如图6所示，缓存数据的更新装置600，可以设置于缓存客户端，包括：接收单元61，配置为接收缓存服务端针对第一数据项推送的推送增量包，其中，推送增量包包括多个连续版本的增量信息；比较单元62，配置为将多个连续版本与缓存客户端中第一数据项的当前数据的最后更新版本进行比较，其中，最后更新版本与当前数据最后一次更新时所依据的增量信息的版本一致；确定单元63，配置为根据比较结果确定对当前数据的更新策略。

根据一个实施方式，比较单元62可以进一步配置为：对比多个连续版本中的最早版本的前一个版本与最后更新版本，最早版本是多个连续版本中最早生成的版本。此时，如果最后更新版本早于最早版本的前一个版本，确定单元63还可以向缓存服务端发送数据请求，以请求最后更新版本之后的各个版本的增量信息。

根据一个实施方式，比较单元62可以进一步配置为：对比多个连续版本中的最新版本与最后更新版本，最新版本是多个连续版本中最晚生成的版本。在最后更新版本不早于最新版本的情况下，确定单元63还可以确定无需更新当前数据。

根据一个实施方式，比较单元62可以进一步配置为：检测最后更新版本是否落入以下版本范围：多个连续版本中的最早版本的前一个版本与多个连续版本中的最新版本的前一个版本之间。在落入的情况下，确定单元63还可以用最后更新版本的后一个版本至最新版本的增量信息更新当前数据。

值得说明的是，图6所示的装置600是与图4示出的方法实施例相对应的装置实施例，图4示出的方法实施例中的相应描述同样适用于装置600，在此不再赘述。

通过以上装置，缓存服务端在第一数据项发生变更时，不仅针对第一数据项生成当前版本的增量信息，而且以当前版本作为最新版本，生成包括多个连续版本的增量信息作为冗余的推送增量包，向至少一个缓存客户端推送。缓存客户端接收上述推送增量包，可以根据多个连续版本的增量信息，确定对当前数据的更新策略。从而可以提高缓存客户端对推送增量包的接受率，并进一步提高增量信息推送的有效性。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图3或图4所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图3或图4所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (22)

1.一种缓存数据的推送方法，用于缓存服务端，所述方法包括：

响应于第一数据项发生变更，根据所述第一数据项的变更信息，针对所述第一数据项生成当前版本的增量信息；

生成推送增量包，所述推送增量包包括多个连续版本的增量信息，所述当前版本为所述多个连续版本中的最新版本；

向至少一个缓存客户端推送所述推送增量包，以供所述至少一个缓存客户端根据所述推送增量包确定对各个缓存客户端中与所述第一数据项对应的当前数据的更新策略。

2.根据权利要求1所述的方法，其中，所述当前版本具有按照所述第一数据项的变更次序确定的当前版本标识。

3.根据权利要求2所述的方法，其中，所述当前版本标识通过在所述第一数据项的前一版本的增量数据的版本标识上增加预定值生成。

4.根据权利要求1所述的方法，其中，所述生成推送增量包包括：

获取增量信息的预定推送版本数；

按照所述预定推送版本数，从所述当前版本开始倒序选取所述预定推送版本数的各个版本的增量信息；

根据所选取的增量信息生成推送增量包。

5.根据权利要求4所述的方法，其中，所述预定推送版本数与所述第一数据项的变更频率正相关。

6.根据权利要求1所述的方法，其中，所述至少一个缓存客户端包括第一缓存客户端，所述方法还包括：

接收所述第一缓存客户端用于获取增量信息的数据请求，所述数据请求由所述第一缓存客户端在以下情况下，根据所述更新策略发出：所述当前数据的最后更新版本，早于所述推送增量包中增量信息的最早版本的前一个版本，所述最后更新版本与所述当前数据最后一次更新时所依据的增量数据版本相一致；

根据所述数据请求向所述第一缓存客户端发送所述最后更新版本与所述当前版本之间的增量信息。

7.一种缓存数据的更新方法，用于缓存客户端，所述方法包括：

接收缓存服务端针对第一数据项推送的推送增量包，其中，所述推送增量包包括多个连续版本的增量信息；

将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较，其中，所述最后更新版本与所述当前数据最后一次更新时所依据的增量信息的版本一致；

根据比较结果确定对所述当前数据的更新策略。

8.根据权利要求7所述的方法，其中，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：

对比所述多个连续版本中的最早版本的前一个版本与所述最后更新版本，所述最早版本是所述多个连续版本中最早生成的版本；以及

根据比较结果确定对所述当前数据的更新策略包括：

在所述最后更新版本早于所述最早版本的前一个版本的情况下，向所述缓存服务端发送数据请求，以请求所述最后更新版本之后的各个版本的增量信息。

9.根据权利要求7所述的方法，其中，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：

对比所述多个连续版本中的最新版本与所述最后更新版本，所述最新版本是所述多个连续版本中最晚生成的版本；以及

根据比较结果确定对所述当前数据的更新策略包括：

在所述最后更新版本不早于所述最新版本的情况下，确定无需更新所述当前数据。

10.根据权利要求7所述的方法，其中，将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较包括：

检测所述最后更新版本是否落入以下版本范围：

所述多个连续版本中的最早版本的前一个版本与所述多个连续版本中的最新版本的前一个版本之间；以及

根据比较结果确定对所述当前数据的更新策略包括：

在落入的情况下，用所述最后更新版本的后一个版本至所述最新版本的增量信息更新所述当前数据。

11.一种缓存数据的推送装置，设置于缓存服务端，所述装置包括：

第一生成单元，配置为响应于第一数据项发生变更，根据所述第一数据项的变更信息，针对所述第一数据项生成当前版本的增量信息；

第二生成单元，配置为生成推送增量包，所述推送增量包包括多个连续版本的增量信息，所述当前版本为所述多个连续版本中的最新版本；

发送单元，配置为向至少一个缓存客户端推送所述推送增量包，以供所述至少一个缓存客户端根据所述推送增量包确定对各个缓存客户端中与所述第一数据项对应的当前数据的更新策略。

12.根据权利要求11所述的装置，其中，所述当前版本具有按照所述第一数据项的变更次序确定的当前版本标识。

13.根据权利要求12所述的装置，其中，所述当前版本标识通过在所述第一数据项的前一版本的增量数据的版本标识上增加预定值生成。

14.根据权利要求11所述的装置，其中，所述第二生成单元进一步配置为：

获取增量信息的预定推送版本数；

按照所述预定推送版本数，从所述当前版本开始倒序选取所述预定推送版本数的各个版本的增量信息；

根据所选取的增量信息生成推送增量包。

15.根据权利要求14所述的装置，其中，所述预定推送版本数与所述第一数据项的变更频率正相关。

16.根据权利要求11所述的装置，其中，所述至少一个缓存客户端包括第一缓存客户端，所述装置还包括数据请求处理单元，配置为：

接收所述第一缓存客户端用于获取增量信息的数据请求，所述数据请求由所述第一缓存客户端在以下情况下，根据所述更新策略发出：所述当前数据的最后更新版本，早于所述推送增量包中增量信息的最早版本的前一个版本，所述最后更新版本与所述当前数据最后一次更新时所依据的增量数据版本相一致；

根据所述数据请求向所述第一缓存客户端发送所述最后更新版本与所述当前版本之间的增量信息。

17.一种缓存数据的更新装置，设置于缓存客户端，所述装置包括：

接收单元，配置为接收缓存服务端针对第一数据项推送的推送增量包，其中，所述推送增量包包括多个连续版本的增量信息；

比较单元，配置为将所述多个连续版本与所述缓存客户端中所述第一数据项的当前数据的最后更新版本进行比较，其中，所述最后更新版本与所述当前数据最后一次更新时所依据的增量信息的版本一致；

确定单元，配置为根据比较结果确定对所述当前数据的更新策略。

18.根据权利要求17所述的装置，其中，所述比较单元还配置为：

对比所述多个连续版本中的最早版本的前一个版本与所述最后更新版本，所述最早版本是所述多个连续版本中最早生成的版本；以及

所述确定单元还配置为：

在所述最后更新版本早于所述最早版本的前一个版本的情况下，向所述缓存服务端发送数据请求，以请求所述最后更新版本之后的各个版本的增量信息。

19.根据权利要求17所述的装置，其中，所述比较单元还配置为：

对比所述多个连续版本中的最新版本与所述最后更新版本，所述最新版本是所述多个连续版本中最晚生成的版本；以及

所述确定单元还配置为：

在所述最后更新版本不早于所述最新版本的情况下，确定无需更新所述当前数据。

20.根据权利要求17所述的装置，其中，所述比较单元还配置为：

检测所述最后更新版本是否落入以下版本范围：

所述多个连续版本中的最早版本的前一个版本与所述多个连续版本中的最新版本的前一个版本之间；

所述确定单元还配置为：

在落入的情况下，用所述最后更新版本的后一个版本至所述最新版本的增量信息更新所述当前数据。

21.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-6或7-10中任一项的所述的方法。

22.一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-6或7-10中任一项所述的方法。