数据同步方法、装置和系统与流程

本申请涉及数据处理技术领域，尤其涉及一种数据同步方法、装置和系统。

背景技术：

客户端从服务端获取数据的过程中，如果数据量比较大，会严重影响客户端的执行效率。为了解决这个问题，可以把服务端的数据放到客户端本地，当客户端需要读取数据的时候，可以直接从本地读取。

数据放到了客户端本地后，会涉及到客户端的数据更新的问题，传统的更新方式是直接以整体覆盖更新的方式重新去服务端整体获取数据，然后删除老数据，存储新数据，这样在触发时机上，通常会采用时间维度或者存储维度等作为触发条件去服务端更新数据。

但是，这种在触发时机上整体覆盖更新的方式，会存在滞后性，并且更新效率差。

技术实现要素：

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的一个目的在于提出一种数据同步方法，该方法可以提高数据更新的实时性，并提高更新效率。

本申请的另一个目的在于提出一种数据同步装置。

本申请的另一个目的在于提出一种数据同步系统。

为达到上述目的，本申请第一方面实施例提出的数据同步方法，包括：获知数据发生变更；在数据发生变更时，生成用于记录数据变更情况的更新日志；将所述更新日志发送给客户端，以使所述客户端根据所述更新日志更新发生变更的本地数据。

本申请第一方面实施例提出的数据同步方法，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

为达到上述目的，本申请第二方面实施例提出的数据同步方法，包括：接收服务端发送的更新日志，所述更新日志是所述服务端在获知数据发生变更时发送的；根据所述更新日志更新发生变更的本地数据。

本申请第二方面实施例提出的数据同步方法，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

为达到上述目的，本申请第三方面实施例提出的数据同步装置，包括：获知模块，用于获知数据发生变更；生成模块，用于在数据发生变更时，生成用于记录数据变更情况的更新日志；发送模块，用于将所述更新日志发送给客户端，以使所述客户端根据所述更新日志更新发生变更的本地数据。

本申请第三方面实施例提出的数据同步装置，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

为达到上述目的，本申请第四方面实施例提出的数据同步装置，包括：接收模块，用于接收服务端发送的更新日志，所述更新日志是所述服务端在获知数据发生变更时发送的；更新模块，用于根据所述更新日志更新发生变更的本地数据。

本申请第四方面实施例提出的数据同步装置，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

为达到上述目的，本申请第五方面实施例提出的数据同步系统，包括：上述两个方面的装置。

本申请第五方面实施例提出的数据同步系统，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一实施例提出的数据同步方法的流程示意图；

图2是本申请实施例中系统结构示意图；

图3是本申请另一实施例提出的数据同步方法的流程示意图；

图4是本申请另一实施例提出的数据同步方法的流程示意图；

图5是本申请另一实施例提出的数据同步方法的流程示意图；

图6是本申请另一实施例提出的数据同步方法的流程示意图；

图7是本申请另一实施例提出的数据同步方法的流程示意图；

图8是本申请另一实施例提出的数据同步方法的流程示意图；

图9是本申请另一实施例提出的数据同步方法的流程示意图；

图10是本申请另一实施例提出的数据同步方法的流程示意图；

图11是本申请另一实施例提出的数据同步方法的流程示意图；

图12是本申请另一实施例提出的数据同步方法的流程示意图；

图13是本申请另一实施例提出的数据同步方法的流程示意图；

图14是本申请另一实施例提出的数据同步方法的流程示意图；

图15是本申请另一实施例提出的数据同步装置的结构示意图；

图16是本申请另一实施例提出的数据同步装置的结构示意图；

图17是本申请另一实施例提出的数据同步装置的结构示意图；

图18是本申请另一实施例提出的数据同步装置的结构示意图；

图19是本申请另一实施例提出的数据同步系统的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。相反，本申请的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1是本申请一实施例提出的数据同步方法的流程示意图，本实施例以服务端的执行流程为例，该方法包括：

S11：获知数据发生变更。

例如，用户可以在位于服务端的业务系统中增加、删除或修改数据，从而服务端获知数据发生变更。业务系统例如为位于服务端的为应用程序(APP)内的功能项提供数据的系统，如为购物类APP的收藏夹提供数据的系统等。

S12：在数据发生变更时，生成用于记录数据变更情况的更新日志。

参见图2，服务端可以具体包括：消息处理中心21，业务系统在自身的数据发生变更后，可以将数据变更情况通知给消息处理中心，消息处理中心根据数据变更情况按照预设格式生成更新日志(updatelog)。另外，在生成更新日志后，消息处理中心可以将更新日志保存在同步消息数据库22内。

S13：将所述更新日志发送给客户端，以使所述客户端根据所述更新日志更新发生变更 的本地数据。

参见图2，服务端还可以包括：消息下发中心23，消息下发中心23用于从同步消息数据库22中读取更新日志并发送给客户端。

另外，参见图2，服务端还可以包括：订阅关系数据库24、用户设备数据库25、全双工网络通道26和用户设备任务状态获取模块27和进度游标记录数据库28。订阅关系数据库24中保存一条或多条订阅关系，订阅关系包括：更新日志与用户、用户设备、APP中的一项或多项之间的关系，以及，用户、用户设备与APP之间的对应关系。用户设备数据库25用于保存用户设备的连接信息。全双工网络通道26是客户端与服务端之间的长连接，可以提供服务端向客户端发送消息以及客户端向服务端发送消息。用户设备任务状态获取模块27用于获取每个用户设备上的更新日志的处理情况相关信息，如未处理的更新日志的数量，每个已处理的更新日志是否处理成功等，之后，将获取的处理情况相关信息记录在进度游标记录数据库28中。

在发送更新日志时，消息下发中心23可以根据订阅关系数据库24中保存的订阅关系确定作为目的地的用户设备，再从用户设备数据库25中获取作为目的地的用户设备的连接信息，再确定与该连接信息对应的全双工网络通道26，通过该全双工网络通道将更新日志发送给用户设备。另外，用户设备可以将根据更新日志的处理情况再通过全双工网络通道发送给消息下发中心，消息下发中心将其保存在进度游标记录数据库28中。

本实施例中，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

一些实施例中，参见图3，S13可以具体包括：

S31：获取同一个用户对应的不同客户端上的更新日志。

例如，同一个用户可以在不同的用户设备上进行登录，从而同一个用户可以对应不同的客户端，同一个用户对应的不同客户端上的更新日志可以相同或不同。

S32：根据所述不同客户端上的更新日志，确定需同步的更新日志，并将需同步的更新日志发送给对应的客户端，以同步不同客户端上的更新日志。

例如，同一个用户在用户设备-1和用户设备-2上都处于登录状态，由于不同用户设备的处理进度可能不同，造成不同的用户设备上可能具有不同的更新日志。例如，对应该同一个用户，更新日志包括：更新日志-1、更新日志-2和更新日志-3，用户设备-1上的更新日志例如包括：更新日志-1和更新日志-2，用户设备-2上的更新日志例如为更新日志-3，此时，可以对应每个用户设备，确定该用户设备上需同步的更新日志，需同步的更新日志是指自身用户设备上没有而其他用户设备上已有的更新日志，例如，对应用户设备-1的需 同步的更新日志是更新日志-3，对应用户设备-2的需同步的更新日志包括更新日志-1和更新日志-2。在对应每个用户设备确定出相应的需同步的更新日志后，可以将需同步的更新日志发送给相应的用户设备，例如，将更新日志-3发送给用户设备-1，将更新日志-1和更新日志-2发送给用户设备-2，从而使得用户设备-1和用户设备-2上的更新日志一致，实现不同用户设备间的更新日志的同步。可以理解的是，上述以发送到用户设备为例，在具体实施例时通常是指发送到用户设备上某个APP所对应的客户端。

本实施例中，通过确定需同步的更新日志，并将其发送给对应的客户端，可以实现多端同步。

一些实施例中，参见图4，当需要发送给客户端的更新日志为多条时，S13可以具体包括：

S41：向客户端发送一条当前的更新日志。

其中，可以将需要发送的每条更新日志依次作为当前的更新日志，例如，首次时，向客户端发送第一条更新日志。

S42：接收客户端发送的对应所述当前的更新日志的响应消息。

例如，客户端接收到第一条更新日志后，可以根据该更新日志进行数据更新，并在数据更新后向服务端发送响应消息。

S43：接收到该响应消息后，发送所述当前的更新日志的下一条的更新日志。

例如，服务端接收到客户端发送的对应第一条更新日志的响应消息后，可以向客户端发送第二条更新日志。

类似的，服务端在接收到客户端发送的对应第二条更新日志的响应消息后，再继续发送第三条更新日志，依此处理，直到将需要发送的多条更新日志发送给客户端。

本实施例中，通过接收到客户端发送的对应前一条更新日志的响应消息后再发送后一条更新日志，可以实现更新日志的序列化发送。

一些实施例中，参见图5，当需要发送给客户端的更新日志为多条时，S13可以具体包括：

S51：同时向客户端发送多条更新日志。

例如，服务端根据每次能够发送的消息数量值，向客户端同时发送相应数量的多条更新日志，直至将需要发送的多条更新日志都发送给客户端。

相应的，客户端也可以向服务端同时发送多条与更新日志对应的响应消息。

本实施例中，通过同时向客户端发送多条更新日志，可以提高发送速度。

一些实施例中，参见图6，当更新日志为多条时，S12之后还可以包括：

S61：获取多条同属于同一个数据源的数据的更新日志。

例如，更新日志中包含业务信息，将包含同一个业务信息的更新日志确定为同属于同一个数据源的数据的更新日志。

S62：将所述多条同属于同一个数据源的数据的更新日志进行合并处理，得到合并处理后的更新日志。

相应的，S13具体包括：

S63：将合并处理后的更新日志发送给客户端，或者，在合并处理后确定不再向客户端发送更新日志时，不再发送更新日志。

例如，多条同属于同一个数据源的数据的更新日志包括：【消息-ADD】-【消息-MOD V2】-【消息-MOD V3】，含义是：先发生了一个增加(ADD)行为，又发生了两次修改(MOD)行为，分别是先修改为V2，再修改为V3，那么经过合并处理后，得到的合并处理后更新日志包括：【消息-ADD】-【消息-MOD V3】，先让客户端增加该数据，然后更新到最新的V3。

又例如，多条同属于同一个数据源的数据的更新日志包括：【消息-MOD】-【消息-DEL】，含义是：先发生了一个MOD行为，然后发生了一个删除(DEL)行为，那么合并处理后的更新日志是：【消息-DEL】，含义是：客户端仅需要发生删除行为。

又例如，多条同属于同一个数据源的数据的更新日志包括：【消息-ADD】-【消息MOD】-【消息DEL】，含义是：先增加一个数据，再修改该数据，最后删除该数据。那么合并处理后的更新日志是空，也就是说客户端不需要对该数据进行处理，因此，此时服务端不需要向客户端发送更新日志。

本实施例中，通过先进行合并处理再发送合并处理后的更新日志或不发送更新日志，可以减少下行数据传输的网络占用时间，以及减少客户端不必要的处理过程。

一些实施例中，参见图7，S13之后还可以包括：

S71：如果没有接收到所述客户端对应所述更新日志的响应消息，则重新发送所述更新日志。

例如，客户端在接收到更新日志后，可以在接收到更新日志或根据更新日志进行数据更新后，向服务端发送响应消息。

如果服务端在预设时间内没有收到该响应消息，则可以重新发送更新日志。

本实施例中，通过服务端重新发送更新日志，可以实现服务端的重试机制，提高下行网络传输的可靠性。

一些实施例中，参见图8，S13之后还可以包括：

S81：接收所述客户端发送的对应所述更新日志的第一响应消息。

例如，客户端在接收到更新日志或根据更新日志更新数据后，向服务端发送响应消息，为了与服务端发送的响应消息区分，此时的响应消息可以称为第一响应消息。

S82：向所述客户端发送对应所述第一响应消息的第二响应消息，以使所述客户端在没有接收到所述第二响应消息时，重新发送所述第一响应消息。

例如，服务端在接收到第一响应消息后可以向客户端发送对应的第二响应消息。

如果客户端没有收到第二响应消息，则可以重新发送对应的第一响应消息。

可以理解的是，更新日志、第一响应消息和第二响应消息中可以包含相同的关联标识，以相互对应。

本实施例中，通过客户端重新发送响应消息，可以实现客户端的重试机制，提高上行网络传输的可靠性。

一些实施例中，参见图9，S13之后还包括：

S91：获取所述客户端未处理的更新日志的数量。

例如，在图2所示的用户设备任务状态数据库中可以记录每个用户设备的处理情况，因此，服务端可以通过在用户设备任务状态数据库中进行查询，获取每个用户设备未处理的更新日志的数量。

S92：如果所述数量大于预设阈值，则向客户端发送过期指令，以使所述客户端根据所述过期指令清理本地数据并从服务端重新获取同步数据。

例如，客户端-1的未处理的更新日志的数量大于预设阈值时，服务端可以向客户端-1发送过期指令，客户端-1接收到该过期指令后，不再根据更新日志进行数据更新，而是以整体覆盖更新的方式重新从服务端获取数据，以实现客户端与服务端的数据同步。

本实施例中，通过在客户端积累大量未处理的更新日志后，不再根据更新日志进行数据更新，可以避免大量的更新日志耗费较长的客户端的处理时间，从而降低对客户端的业务使用的影响。

一些实施例中，参见图10，S13之后，还包括：

S101：当所述更新日志中包含的数据在客户端被标记为过期时，接收所述客户端发送的过期通知消息。

例如，客户端可以将预设时间(如7天)内未使用的数据标记为过期，如果客户端接收的更新日志中包含过期数据，则客户端不再根据该更新日志进行数据更新，并且向服务端发送过期通知消息。

服务端在接收到针对数据的过期通知消息后，可以在后续的预设时间内不再发送包含过期数据的更新日志。

本实施例中，通过客户端发送的针对过期数据的过期通知消息，可以提高更新日志的发送效率，避免发送无用的更新日志。

图11是本申请另一实施例提出的数据同步方法的流程示意图，本实施例以客户端的执 行流程为例，该方法包括：

S111：接收服务端发送的更新日志，所述更新日志是所述服务端在获知数据发生变更时发送的。

例如，如上述实施例所示，服务端可以获知服务端的数据发生变更，服务端在获知数据发生变更时，可以根据变更情况生成更新日志，之后，服务端可以将更新日志发送给客户端。

S112：根据所述更新日志更新发生变更的本地数据。

其中，更新日志中可以包括如下参数：

【commandId】:命令唯一性编号，客户端用此编号来处理重复指令等。

【ds】：当前数据归属的业务的代码，每个业务数据都有唯一性代码。

【data】：发生变更的数据内容。

【version】：发生变更后的数据版本号。

【operate】：数据变更类型，包括：增加(ADD)、删除(DEL)、修改(MOD)。

客户端根据上述格式的更新日志更新发生变更的本地数据可以具体包括：

对本地数据中的所述更新日志中包括的发生变更的数据内容，进行所述更新日志中包括的操作指令对应的操作。

例如，操作指令(operate)是增加(【ADD】)时，将发生变更的数据内容(【data】)添加到本地数据中。

又例如，操作指令(operate)是删除(【DEL】)时，将发生变更的数据内容(【data】)在本地数据中删除。

又例如，操作指令(operate)是删除(【MOD】)时，将业务【ds】对应的数据修改为发生变更的数据内容(【data】)，并将数据版本修改为【version】指示的版本号。

一些实施例中，参见图12，在S112之前，该方法还可以包括：

S121：判断是否需要处理更新日志，若是，执行S112，否则执行S122。

其中，可以根据如下项中的一项或多项判断是否需要处理更新日志：

判断更新日志是否是重复指令，当是重复指令时确定不需要处理，否则需要处理。其中，可以根据commandID判断是否是重复指令。

判断更新日志中包含的数据是否被标记为过期，当被标记为过期时确定不需要处理，否则需要处理。其中，客户端可以将预设时间(如7天)内未使用的数据标记为过期，从而可以确定更新日志中包含的数据是否被标记为过期。

判断所述更新日志中包含的数据的版本是否比本地数据的版本新，当本地数据的版本更新时，不需要处理，否则需要处理。其中，更新日志中包含版本号，并且本地数据中也 可以对应配置版本号，因此，可以比较两个版本号，得到判断结果。

判断客户端当前所处的状态是否属于预设状态，如果不属于预设状态可以确定不需要处理更新日志，否则需要处理，其中，预设状态包括：初始化成功、初始化失败、同步成功或同步失败。其中，客户端可以根据当前处理情况更新状态，客户端所处的状态可以分为：未初始化、初始化成功、初始化失败、同步成功、同步失败和数据过期。

S122：不处理所述更新日志。

另外，在数据过期时，客户端还可以向服务端发送过期通知消息。

另外，在更新日志中的版本信息较旧时，客户端还可以向服务端发送版本错误的信息。

本实施例中，通过先进行是否需要处理更新日志的判断，可以在不需要时不处理更新日志，避免资源浪费。

一些实施例中，参见图13，该方法还可以包括：

S131：根据初始化行为或者标记行为进行初始化，得到初始化状态，所述初始化状态包括：未初始化、初始化成功或者初始化失败。

初始化是客户端进行本地数据的初始化。

初始化行为可以包括：APP初始化、数据被读取时、业务模块主动触发。

通过上述初始化行为可以实现数据的初始化。

另外，初始化也可以是标记行为，例如，仅被标记为初始化成功，而没有实际上的初始化行为。

在S122之后，还可以包括：

S132：根据所述更新日志更新发生变更的本地数据后，得到同步状态，所述同步状态包括：同步成功或同步失败；

另外，还可以包括：

S133：根据数据的使用情况，将预设时间内未使用的数据标记为过期，得到数据过期状态。

例如，如果数据A在预设时间内未被读或写，则客户端将其标记为过期，之后如果客户端接收到对A的更新日志后，不处理该更新日志。

本实施例中，通过确定客户端的状态，可以有效确定是否处理更新日志。

一些实施例中，参见图14，该方法还可以包括：

S141：对订阅了所述更新日志的业务方进行回调通知。

例如，业务方-1向客户端订阅了ds-1的更新日志，则客户端接收到ds-1的更新日志后，不仅可以根据该更新日志进行客户端本地数据的更新，还可以将该更新日志发送给业务方-1，从而业务方-1可以根据该更新日志进行后续处理，如更新业务方内部的数据。

本实施例中，通过对订阅了更新日志的业务方进行回调通知，可以方便业务方的有效处理。

另外，类似对服务端的处理，客户端还可以执行如下内容：

一些实施例中，所述接收服务端发送的更新日志，包括：

接收服务端发送的需同步的更新日志，所述需同步的更新日志是所述服务端根据不同客户端上的更新日志确定的。

一些实施例中，当需要发送给客户端的更新日志为多条时，所述接收服务端发送的更新日志，包括：

接收服务端发送的一条当前的更新日志，以及，向服务端发送对应所述当前的更新日志的响应消息，以使所述服务端在接收到所述响应消息后发送所述当前的更新日志的下一条的更新日志；或者，

接收服务端同时发送的多条更新日志。

一些实施例中，当需要发送给客户端的更新日志包括：多条同属于同一个数据源的数据的更新日志时，所述接收服务端发送的更新日志，包括：

接收服务端发送的合并处理后的更新日志，或者，在服务端合并处理后确定不需要向客户端发送更新日志时，不接收服务端发送的更新日志，所述合并处理后的更新日志是所述服务端将所述多条同属于同一个数据源的数据的更新日志进行合并处理后得到的。

一些实施例中，还包括：

向所述服务端发送对应所述更新日志的响应消息，以使所述服务端在没有接收到所述响应消息时重新发送所述更新日志。

一些实施例中，还包括：

向所述服务端发送对应所述更新日志的第一响应消息，以使所述服务端在在接收到所述第一响应消息后向所述客户端发送对应所述第一响应消息的第二响应消息；

如果没有接收到所述第二响应消息，重新向所述服务端发送所述第一响应消息。

一些实施例中，还包括：

接收所述服务端发送的过期指令，所述过期指令是所述服务端在确定所述客户端未处理的更新日志的数量大于预设阈值后发送的；

根据所述过期指令清理本地数据，并从服务端重新获取同步数据。

具体内容可以参照服务端的相关描述，在此不再赘述。

通过上述方式可以提高更新日志的准确性和高效性。

图15是本申请另一实施例提出的数据同步装置的结构示意图，该装置位于服务端，该装置150包括：获知模块151、生成模块152和发送模块153。

获知模块151，用于获知数据发生变更；

生成模块152，用于在数据发生变更时，生成用于记录数据变更情况的更新日志；

发送模块153，用于将所述更新日志发送给客户端，以使所述客户端根据所述更新日志更新发生变更的本地数据。

一些实施例中，发送模块153具体用于：

获取同一个用户对应的不同客户端上的更新日志；

根据所述不同客户端上的更新日志，确定需同步的更新日志，并将需同步的更新日志发送给对应的客户端，以同步不同客户端上的更新日志。

一些实施例中，当需要发送给客户端的更新日志为多条时，发送模块153具体用于：

向客户端发送一条当前的更新日志，并在接收到客户端发送的对应所述当前的更新日志的响应消息后，发送所述当前的更新日志的下一条的更新日志；

或者，

同时向客户端发送多条更新日志。

一些实施例中，当需要发送给客户端的更新日志包括：多条同属于同一个数据源的数据的更新日志时，参见图16，该装置还包括：

合并模块154，用于将所述多条同属于同一个数据源的数据的更新日志进行合并处理，得到合并处理后的更新日志；

发送模块153具体用于：将合并处理后的更新日志发送给客户端，或者，在合并处理后确定不再向客户端发送更新日志时，不再发送更新日志。

一些实施例中，发送模块153还用于：如果没有接收到所述客户端对应所述更新日志的响应消息，则重新发送所述更新日志。

一些实施例中，参见图16，该装置还包括：

接收模块155，用于接收所述客户端发送的对应所述更新日志的第一响应消息；

所述发送模块153还用于：向所述客户端发送对应所述第一响应消息的第二响应消息，以使所述客户端在没有接收到所述第二响应消息时，重新发送所述第一响应消息。

一些实施例中，参见图16，该装置还包括：

获取模块156，用于获取所述客户端未处理的更新日志的数量；

所述发送模块153还用于：如果所述数量大于预设阈值，则向客户端发送过期指令，以使所述客户端根据所述过期指令清理本地数据并从服务端重新获取同步数据。

一些实施例中，接收模块155还用于：当所述更新日志中包含的数据在客户端被标记为过期时，接收所述客户端发送的过期通知消息。

上述模块的具体内容可以参见上述方法实施例中的相关描述。

本实施例中，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

图17是本申请另一实施例提出的数据同步装置的结构示意图，该装置位于客户端，该装置170包括：接收模块171和更新模块172。

接收模块171，用于接收服务端发送的更新日志，所述更新日志是所述服务端在获知数据发生变更时发送的；

更新模块172，用于根据所述更新日志更新发生变更的本地数据。

一些实施例中，所述接收模块171具体用于：

接收服务端发送的需同步的更新日志，所述需同步的更新日志是所述服务端根据不同客户端上的更新日志确定的。

一些实施例中，当需要发送给客户端的更新日志为多条时，所述接收模块171具体用于：

接收服务端发送的一条当前的更新日志，以及，向服务端发送对应所述当前的更新日志的响应消息，以使所述服务端在接收到所述响应消息后发送所述当前的更新日志的下一条的更新日志；或者，

接收服务端同时发送的多条更新日志。

一些实施例中，当需要发送给客户端的更新日志包括：多条同属于同一个数据源的数据的更新日志时，所述接收模块171具体用于：

接收服务端发送的合并处理后的更新日志，或者，在服务端合并处理后确定不需要向客户端发送更新日志时，不接收服务端发送的更新日志，所述合并处理后的更新日志是所述服务端将所述多条同属于同一个数据源的数据的更新日志进行合并处理后得到的。

一些实施例中，参见图18，该装置还包括：

第一发送模块173，用于向所述服务端发送对应所述更新日志的响应消息，以使所述服务端在没有接收到所述响应消息时重新发送所述更新日志。

一些实施例中，参见图18，该装置还包括：

第二发送模块174，用于向所述服务端发送对应所述更新日志的第一响应消息，以使所述服务端在在接收到所述第一响应消息后向所述客户端发送对应所述第一响应消息的第二响应消息；

第三发送模块175，用于如果没有接收到所述第二响应消息，重新向所述服务端发送所述第一响应消息。

一些实施例中，参见图18，所述接收模块171还用于：

接收所述服务端发送的过期指令，所述过期指令是所述服务端在确定所述客户端未处理的更新日志的数量大于预设阈值后发送的；

所述装置还包括：

清理模块176，用于根据所述过期指令清理本地数据，并从服务端重新获取同步数据。

一些实施例中，参见图18，该装置还包括：

通知模块177，用于对订阅了所述更新日志的业务方进行回调通知。

一些实施例中，所述更新日志中包括：操作指令和发生变更的数据内容，所述更新模块72具体用于：

在本地数据中，对所述更新日志中包括的发生变更的数据内容，进行所述更新日志中包括的操作指令对应的操作。

一些实施例中，参见图18，该装置还包括：

判断模块178，用于判断如下项中的一项或多项：

判断所述更新日志是否是重复指令，以便在不是重复指令时根据所述更新日志更新本地数据，否则，不处理所述更新日志；

判断所述更新日志中包含的数据是否被标记为过期，以便在没有标记为过期时根据所述更新日志更新本地数据，否则，不处理所述更新日志，并向所述服务端发送过期消息；

判断所述更新日志中包含的数据的版本是否比本地数据的版本新，以便在更新日志中包含的数据的版本比本地数据的版本新时，根据所述更新日志更新本地数据，否则，不处理所述更新日志；

判断客户端当前所处的状态是否属于预设状态，以便在属于预设状态时，根据所述更新日志更新本地数据，否则，不处理所述更新日志，所述预设状态包括：初始化成功、初始化失败、同步成功或同步失败。

一些实施例中，参见图18，该装置还包括：

状态确定模块179，用于执行如下项中的一项或多项：

根据初始化行为或者标记行为进行初始化，得到初始化状态，所述初始化状态包括：未初始化、初始化成功或者初始化失败；

根据所述更新日志更新发生变更的本地数据后，得到同步状态，所述同步状态包括：同步成功或同步失败；

根据数据的使用情况，将预设时间内未使用的数据标记为过期，得到数据过期状态。

上述模块的具体内容可以参见上述方法实施例中的相关描述。

本实施例中，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可 以提高更新效率，避免资源浪费。

图19是本申请另一实施例提出的数据同步系统的结构示意图，该系统190包括服务端装置191和客户端装置192。其中，服务端装置可以如图15或图16所示，客户端装置可以如图17或图18所示。

上述模块的具体内容可以参见上述方法实施例中的相关描述。

本实施例中，通过在数据发生变更时，将更新日志发送给客户端，可以降低滞后性，从而提高数据更新的实时性，另外，通过更新发生变更的本地数据，而不是整体更新，可以提高更新效率，避免资源浪费。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、 或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。