CN103297529A

CN103297529A - 基于时间戳的树型结构数据同步方法

Info

Publication number: CN103297529A
Application number: CN2013102228982A
Authority: CN
Inventors: 尹建伟; 严皓亮; 李莹; 吴健; 邓水光; 吴朝晖
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2013-06-06
Filing date: 2013-06-06
Publication date: 2013-09-11
Anticipated expiration: 2033-06-06
Also published as: CN103297529B

Abstract

本发明涉及面向树型结构的数据同步，公开了基于时间戳的树型结构数据同步方法，包括数据中心服务器集群和客户端，数据中心服务器集群包括多个服务器，数据中心服务器集群和客户端采用星型拓扑结构，包括以下具体步骤：客户端向服务器注册、客户端发起同步、服务端响应同步、客户端确认。本发明的优点在于，充分考虑了树形结构数据的结构特征，减少了同步过程中的通讯数据，提高了同步效率，具有较高的应用价值。

Description

基于时间戳的树型结构数据同步方法

技术领域

本发明涉及面向树型结构的数据同步，特别涉及一种基于时间戳的树型结构数据同步方法。

背景技术

数据同步是使存在关联映射关系的两个数据集中的数据元素的等价的操作，任意一个数据集中的更新都会被同步传递到另一个数据集中。树型数据的同步则是发生在客户端与服务端之间的两棵树之间的等价操作，其中两棵树之间可能完全相同，也可能一棵树为另一棵树子树。树型同步操作的基本单元就是树型元素节点，而同步就是使发生在一个数据集中的元素修改传递到另一个集合中。

同步协议的评价标准一般包括几个方面：适用规模、传输负载、计算复杂度以及存储空间。同步系统的拓扑结构往往决定了系统的适用规模，在相同拓扑结构下，合理的任务分配也会给适用规模带来改善；传输负载主要是考虑移动互联网的不稳定性，较低的传输负载可以加快同步过程，减少数据流量；计算复杂度和存储空间也主要考虑移动端设备的计算能力优先。

近年来提出了很多移动设备与服务器间的同步方案，以下列举常用的几种方案并进行了一些分析比较：

1) ActiveSync

ActiveSync是微软提出的，支持终端与桌面系统同步的产品，具有较小的计算强度与存储消耗，较适用于个人应用。

2) CPISync

CPISync是Cornell大学的学者基于他们所提出的集合一致化(Set Reconcile)算法设计实现的一种同步方式。这一同步方案的计算量主要与参与同步的数据项中差异项目数相关，与数据集本身体积关系不大。由于该方案对数据集进行摘要，并对同步双方数据进行计算，有较高的计算复杂度，但是其通讯数据量较低，而又不需要额外的辅助存储空间。其算法特征决定了该方案可以应用于P2P的同步场景中，从而具有较大的可扩展性。

3) SyncML

SyncML具有普遍适用的特征，对同步双方的数据类型、网络类型、协议类型等没有特殊要求，是一个开放式的规范。由于协议的目标为通用性，因此在数据解析等方面有较大开销。

上述现有的移动设备同步方案中，同步的通信负载基本都与需要更新的数据记录数成正比，而具有最优通信负载的CPISync方案又有较高的计算复杂度，因此不适用于树型数据的同步方案。

发明内容

本发明针对现有技术无法适用于具有树形结构的同步数据的缺点，提供了一种新型的基于时间戳的树型结构数据同步方法。

为实现上述目的，本发明可采取下述技术方案：

基于时间戳的树型结构数据同步方法，包括数据中心服务器集群和客户端，数据中心服务器集群包括多个服务器，数据中心服务器集群和客户端采用星型拓扑结构，包括以下具体步骤：

1）客户端向服务器注册：客户端通过用户名和/或密码的方式向中心服务器注册，所述中心服务器为星形拓扑结构的中央节点，每一个注册的客户端以(user, client)二元组的形式在服务器保存，并通过状态管理服务器对二元组进行管理；

2）客户端发起同步：当客户端到达同步时间窗口、客户端数据发生变更或者客户端经过长时间静默后产生突发的数据访问时，客户端将对服务器保存的数据进行同步；

3）服务端响应同步：服务器收到客户端的同步请求后，对同步请求进行处理，具体包括以下步骤：

3.1）身份验证：身份验证包括用户身份验证和用户权限认证，所述用户身份验证为验证客户端的同步请求是否为合法用户的同步请求，所述用户权限认证为验证同步请求是否在用户的权限范围内，对客户端的身份验证由权限管理器完成；

3.2）时间戳检查：通过身份验证后，服务器检查同步时间戳，服务器分别为每个(user, client)二元组保存了一个Last时间戳，Last时间戳用以标识用户和客户端之间最后一次正常完成的同步请求时间；如果同步请求中不包括上一次同步请求的Last时间戳，但服务器存在，则表示上一次同步请求中服务器的反馈信息未得到客户端确认，该上一次同步请求无效，服务器返回错误信息和上一次同步请求的Last时间戳；如果同步请求中包含有上一次同步请求的Last时间戳，则服务器对比服务器上保存的上一次同步请求的Last时间戳与同步请求中包含的上一次同步请求的Last时间戳，若两者一致，则确认完成，否则服务器向客户端返回错误信息；客户端的同步日志管理器通过对同步日志的时序保证，确定在前一次同步请求的操作完成并得到服务器确认后，才进行下一次同步请求；

3.3）处理同步请求：服务器检查同步请求中客户端的节点ID与该节点的Last时间戳，如果客户端的节点的Last时间戳与服务器中相应节点的Last时间戳一致，服务器返回数据未改变信息，并附加该次请求的Next时间戳，标识该次同步请求已完成；如果服务器相应节点的Last时间戳晚于客户端的节点的Last时间戳，服务器将此相应节点的节点信息以及该节点的所有子节点的节点信息返回给客户端，并将客户端的节点和服务器中相应节点的状态设置为数据已更改，节点信息包括节点ID、数据和Last时间戳，子节点的节点信息包括节点ID和Last时间戳；服务器发送反馈请求后，将服务端对应的Last时间戳更新为同步请求的Next时间戳，用于下一次同步请求的时间戳检查步骤；

4）客户端确认：客户端收到服务器返回信息后，比对返回信息中的Next时间戳和同步请求中的Next时间戳，如果两者一致，表示同步已经完成，更新同步日志中本次同步的状态为已完成，更新同步日志中状态为已完成的上一次同步的状态为已确认；

其中，客户端通过以下步骤确定同步时间窗口：

2.1）客户端启动时，初始化时间t₀为当前时刻，将Count与Avg进行初始化为0，将?t初始化为预设的初始值，其中，Count表示时间间隔?t内客户端对服务器的同步请求的次数，Avg表示客户端对服务器的同步请求的平均次数，?t为两个同步时间窗口的间隔时间；

2.2）在t₀至t₀+?t的时间段内，如果客户端发起同步请求，则更新Count和Avg的数值；

2.3）根据以下公式计算并重新确定?t，确定下一个同步时间窗口：，

Figure 2013102228982100002DEST_PATH_IMAGE004

，其中u为预设值，k为常量；

2.4）间隔时间?t届满时，重复步骤2.1。

作为优选，所述步骤2还包括以下的同步策略：层序同步策略、增量同步策略、慢同步策略和刷新同步策略。

作为优选，客户端登录服务器后检查服务器更新并执行层序同步策略；客户端发生数据改变时，客户端改变同步日志并执行增量同步策略；当客户端在执行增量同步策略的过程中发生同步失败、网络条件改善或者用户端主动请求时执行慢同步策略；当层序同步策略、增量同步策略和慢同步策略均失败时，执行刷新同步策略。

作为优选，执行层序同步策略、增量同步策略和慢同步策略时还包括以下步骤：

1’）生成同步日志：客户端的同步日志管理器生成一个包含同步类型和同步数据的多元组的同步日志，多元组包括同步请求的时间戳Anchor、同步请求的类型Action、新增节点时临时生成的本地节点唯一标识符LUID、相关节点的全局唯一标识符GUID、相关节点的最后更新时间戳TS、更改前的节点数据Original、更改后的节点数据Target、同步状态Status；

2’)发送同步请求：同步请求包括身份验证信息和时间戳信息，其中时间戳信息包括Next时间戳和Last时间戳，Next时间戳表示当前需要进行的同步的时间戳，与生成的同步日志的同步请求的时间戳Anchor相一致，Last时间戳表示上一次确认状态为已完成的同步的时间戳，该时间戳向服务器确认上一次同步的完成状态；若本次同步为客户端和服务器之间的首次同步，则Last时间戳留空；同步请求发送后，更新同步日志中相应日志的状态为等待。

作为优选，所述步骤3还包括以下步骤：数据中心服务器集群的时间戳管理器生成双重时间戳以保证客户端对节点数据访问的时效性，双重时间戳包括节点本身的时间戳和用户授权访问范围的时间戳，其中，节点本身的时间戳标识了节点的最后修改时间，服务器存储的每个节点都有相应的时间戳，每次对节点的修改或者访问都将更新该节点及其父节点的时间戳；用户授权访问范围的时间戳标识用户的数据访问范围的变化情况，每一个(user, client)二元组都设定有一个用户授权访问范围的时间戳，当客户端首次注册时，该时间戳被预设为0，客户端进行同步时，将节点的时间戳与客户端时间戳的较大值作为最终的时间戳；当用户权限范围发生改变时，更新该用户所有注册客户端的时间戳，下一次进行同步时将以该时间戳为准，而二元组的时间戳将在一次成功同步后重新置零，从而避免重复的数据检查。

层序同步策略是指客户端在已经登陆的情况下检查服务器端更新。层序同步策略有两种情况：客户端无已缓存的节点与客户端已有缓存节点。前者服务器端将返回所有的根节点以及根节点的最后修改时间。在实际应用中，根节点可能为一个或多个。在后者的场景中，由于客户端以移动设备为主，因此采用按需动态加载的模式，即只有在访问某节点时才动态请求同步该节点的子节点。在这种模式下，层序同步自上而下地检查已缓存的数据节点的一致性，即在发起同步请求的时候携带需要检查的节点或节点列表。对于首次登陆或客户端主动请求同步的情况，请求也不带节点列表，服务端将默认返回根节点列表。

对服务器来说，若同步请求中未携带节点信息，服务端将视为根节点同步，此时服务器返回数据节点ID及其最后修改的时间戳。如果同步请求总包含了节点列表，则服务器首先检查节点列表是否在访问权限内。对于权限内的合法请求，分别检查每个节点的最后修改时间戳。没有改变的节点返回节点无更新，已删除的节点返回节点删除，已修改的节点则返回节点修改，同时返回已修改节点的信息以及已修改节点的子节点信息。

客户端收到服务器反馈后，逐个检查返回值。对于节点无更新的，表明该节点以及所有子节点都处于最新状态。节点已删除的，则直接删除该节点与其所有子节点。节点已更改的，则修改该节点信息，同时逐个检查每个子节点的时间戳，对有改变的节点发起下一轮同步请求。

在服务端数据没有发生变化的情况下，层序同步可以一次完成确认，最差情况下，层序同步的次数也只与客户端树的层数相关，因此层序同步是比较高效的。

增量同步策略

增量同步是指客户端发生数据改变时，以改变日志的方式向服务器端发起的同步请求。当客户端对数据节点进行修改或删除时，客户端先生成带同步锚的改变日志，并向服务器发起增量同步请求，请求中携带操作类型，操作节点GUID以及节点的新值（修改操作）。服务器端完成数据更新后，将新的节点最后修改时间戳返回给客户端，客户端确认同步锚后将数据更新到本地。同时更新修改节点至根节点的所有最后修改时间戳。

当客户端进行新增节点操作时，客户端需要临时生成LUID，并将改变日志发送至服务器。服务器完成数据更新后，将新产生的GUID与请求发送的LUID同时返回给客户端。客户端用GUID代替LUID完成数据更新。

在增量同步过程中，如果由于网络异常等原因产生同步失败，则同步转为慢同步，改变日志内容将先更新到本地数据库（新增操作中，GUID由LUID代替，完成慢同步后统一更新）。

慢同步策略

当客户端的增量同步过程中发生同步失败时，将由增量同步转为慢同步，在网络条件改善或用户主动请求时进行。慢同步过程中，对于增加节点操作，若服务器端父节点存在，则服务器端进行增加操作，否则回滚增加节点操作；删除节点操作，若服务器端该节点存在，则删除该节点，若不存在，客户端不需回滚；编辑节点操作，若服务器端与客户端更改前版本一致，则更改服务器端数据，否则根据用户设置或系统设置采取保留服务器端版本或保留客户端版本数据。

慢同步时，客户端可能存在一条或多条改变记录。不同的改变记录可能存在包含关系，或者可能不同改变操作作用于同一节点，其效果可以被合并，从而提高同步效率。存在操作合并的情况包括以下几种：

a) 针对同一节点，若最后一项操作为删除操作，则之前所有操作均可忽略，统一为删除操作；

b) 针对同一节点，在不存在删除操作的情况下，将最后一次的编辑操作作为最终的值；

c) 针对多个节点的删除操作，若不同节点间存在祖先关系，则可合并为删除最顶层节点（深度最小）。

改变记录合并后，被合并的操作直接从改变记录中删除，只留下合并以后的改变记录，从而减少同步次数，提高同步效率。

刷新同步策略

刷新同步是指删除所有客户端缓存，重新同步所有数据。当上述所有同步都失效时，可以采用刷新同步将本地数据清空，恢复到服务器状态。刷新同步效率低下，严重影响同步性能，因此只在系统出现严重错误时才建议使用。

客户端发起同步时机选择

按照客户端对树型节点的访问频率采取不同的Pull触发策略是很有必要的。对访问活跃的客户端较频繁地更新客户端缓存，而对于相对不活跃的客户端则相对弱化缓存的作用。

我们用客户端

Figure 2013102228982100002DEST_PATH_IMAGE006

在过去一段时间内的平均数据节点访问次数来描述该客户端的状态，即活跃程度。表示时间间隔，

Figure 2013102228982100002DEST_PATH_IMAGE010

表示在

的时间间隔内客户端

对节点数据的请求次数。

Figure 2013102228982100002DEST_PATH_IMAGE012

表示最近一段时间内该客户端在单位时间间隔

内的平均访问次数。显然地，

可以标识该客户端在最近一段时间内的活跃度。于是有：

Figure 2013102228982100002DEST_PATH_IMAGE014

如果我们用

Figure 2013102228982100002DEST_PATH_IMAGE016

标识客户端两次缓存同步间隔，则有：

Figure 2013102228982100002DEST_PATH_IMAGE018

其中u为一个经验阈值，或者在应用中根据实际情况进行调整，k为一个常量。当平均访问次数高于阈值u时，即客户端处于活跃状态时，间隔一定时间对客户端树型节点缓存进行一次更新；当平均访问次数低于阈值u时，客户端处于非活跃状态，此时停止自动更新客户端缓存，直到下一次客户端对数据节点产生访问。

本发明由于采用了以上技术方案，具有显著的技术效果：

适用于具有树形结构的同步数据，克服了现有技术中所存在的通信数据流量过大的问题，较大地减少了同步过程中的数据流量。相比现有技术，本发明的计算复杂度较低，用于同步过程所需要的临时存储空间也较小，更为适应移动设备的数据同步。

附图说明

图1为树型结构存储的服务端/客户端的结构示意图。

图2为同步过程的简要流程示意图。

图3为同步过程的详细流程示意图。

具体实施方式

下面结合实施例对本发明作进一步的详细描述。

实施例1

本发明主要针对C/S架构的树型数据同步场景设计，整个系统采用星形拓扑架构，由数据中心服务器集群和客户端组成，其中数据中心服务器集群为服务端，包括同步管理器、状态管理器、权限管理器、缓存管理器、时间戳管理器、数据抽象器、分布式存储管理器。客户端包括同步管理、缓存存储管理器、同步日期管理器。整个系统支持大规模高并发访问与服务器的动态扩展，其结构如附图1所示。数据中心服务器的主要功能是存储完整的树型数据副本以及权限管理信息，以提供树型数据的授权访问。

客户端通过本地数据访问接口实现对树型缓存数据的访问，其中树型缓存数据通过缓存存储管理器进行管理。缓存存储管理器根据本地数据访问需求，与同步管理器进行数据交互，通过同步管理器获取以及更新服务器端数据，同步日志管理器通过同步日志实现每次同步的完整性与数据一致性。

服务器端对应地通过同步管理器实现客户端同步请求的接收与处理。服务器端同步管理器综合状态管理器、权限管理器与缓存管理器的相关数据实现对数据的有效访问与更新。状态管理器对用户/客户端的注册状态进行保存，客户端用户登陆后，将在服务器保留其用户/客户端状态，并生成其相应的权限状态。权限状态的管理通过权限管理器实现。一方面权限管理器提供权限更新接口，为管理员修改用户权限提供方法，另一方面权限管理器在用户登陆后在缓存管理器中生成用户权限缓存，从而在用户发起同步或数据请求后能够快速对用户的数据访问进行鉴权操作。缓存管理器配合权限管理器实现对数据的缓存，当同步管理器进行数据请求时，缓存管理器综合权限缓存与数据缓存，返回相应的数据或数据更新结果。状态管理器、权限管理器与缓存管理器通过时间戳管理器实现各项操作的时序性。作为核心部件的时间戳管理器，不仅通过时间戳保证数据项的原子操作，也保证了用户对数据的有序访问，保证了数据的安全性，为数据冲突解决方案提供依据。树型数据抽象器是底层分布式存储管理器与顶层树型节点操作控制器的中间部件，通过对树型节点的抽象，提供树型数据结构的增加、删除、更新以及查询等操作。

在客户端与服务端各部分的综合作用下，客户端可通过适当的方式实现对服务器端授权数据的有效访问，其访问过程简单描述如附图2所示。客户端用户登陆后，将在服务器保留其用户/客户端状态，并生成其相应的权限状态。当用户发起同步请求后，代理访问服务器将通过权限管理服务器进行权限验证，权限验证后，对树型数据进行访问，结合状态服务器信息，对同步请求进行相应。树型数据的变更将直接对同步产生影响，而用户权限变更将通过状态服务器变化，间接地对客户端同步产生影响。通过对用户进行分域管理，可以将应用接口层服务分发到不同服务器中进行，而底层数据层服务通过分布式文件系统进行扩展存储访问，从而实现系统的可扩展性。

同步过程具体实施步骤如图3所示：

步骤一：客户端向服务器注册

客户端通过用户名/密码等方式在不同设备上向中心服务器注册，每一个注册的客户端将以(user, client)的二元组在服务端保存，user为用户ID，client为设备ID。附图1中的状态管理器实现对注册客户端的有效管理。假定用户user分别在不同客户端向服务器注册了(user, client1), (user, client2)。

步骤二：客户端发起同步

当客户端到达同步时间窗口或客户端产生数据变更或客户端长时间静默后产生突发的数据访问时，客户端将对服务器数据进行同步请求。本发明采用客户端主动pull的方式实现数据同步。客户端通过以下步骤确定同步时间窗口：

客户端启动时，初始化时间

Figure 2013102228982100002DEST_PATH_IMAGE020

为当前时刻，将Count与Avg进行初始化为0。此时

为预设的初始值。其中Count表示时间间隔t内客户端对服务器的数据请求次数，Avg为客户端对数据请求的平均次数，为两次同步时间窗口的时间间隔。

在

到

Figure 2013102228982100002DEST_PATH_IMAGE024

的时刻内，如果客户端发起对数据节点的请求，则对Count进行更新，同时更新Avg。

根据公式计算并重新设定，确定下次发起同步的同步时间窗口。

一个周期t后，重复上述步骤1。

到达同步时间窗口后，客户端发生层序同步操作。增量同步与慢同步的发起过程与层序同步类似。我们以层序同步为例，说明发起同步时，必须完成的各项操作：

生成同步日志。同步日志为一个包含同步类型与同步数据的多元组，可以表示为(Anchor, Action, LUID, GUID, TS, Original, Target, Status)，其中Anchor为该次同步的时间戳或者同步锚，Anchor唯一标识了该次同步，Action为同步的类型，包括层序同步、增加、更新、删除等不同类型，LUID表示增加节点操作时，本地客户端为新增节点所临时生成的本地唯一标识符，GUID为与操作相关的节点的全局唯一标识符，GUID与服务器端保存的相关节点的节点ID相一致，TS为该节点的最后更新时间戳，Original为更改前的节点数据，Target为更改后的节点数据，Status为该次同步状态。同步日志管理器为客户端的核心部件，如附图1所示。

发送同步请求。同步请求包含身份认证信息与时间戳信息。时间戳信息包含两方面，其中Next时间戳表示当前需要进行的同步的时间戳，与生成的同步日志中的Anchor一致，Last时间戳表示上一次确认完成的时间戳，该时间戳向服务器确认上一次同步完成状态。若该次同步为该客户端/用户首次同步，则Last时间戳留空。同步请求发送后，同步日志中相应记录的状态更新为“waiting”或者等待。客户端同步请求流程由同步管理器在同步日志管理器的协同作用下完成，与客户端缓存存储管理器无直接作用，如附图1所示。

步骤三：服务端响应同步

同步过程中，针对特定用户的节点的时间戳包含两部分的含义：

数据节点本身的时间戳。该时间戳在每次数据更新后更新，并且一个节点的时间戳更新将同时影响到其所有祖先节点的时间戳更新。

用户授权访问范围的时间戳。

这两个时间戳概念均由服务器端的时间戳管理器产生并传输给各个模块，如附图1所示。针对这两种不同场景产生的用户数据变更，服务端采用双重时间戳保证客户端对数据节点数据访问的时效性：

数据节点本身的时间戳。服务端存储的每个树型节点都有相应的时间戳，其标识了该数据节点的最后修改时间。每次对数据节点的修改访问都将更新该节点以及其祖先节点的时间戳。

用户授权访问范围的时间戳。在用户/客户端注册的步骤中，客户端注册后将在中心服务器保存(user, client)二元组。为每个二元组设定用户授权访问范围的时间戳，标识该用户的数据访问范围变化情况。当客户端首次注册时，该时间戳被预设为0，该客户端进行数据同步时，我们采用数据节点时间戳与用户/客户端时间戳的较大值作为最终的时间戳。正常情况下，该时间戳为0，数据节点的时间戳即该用户访问时的时间戳；当用户权限范围发生改变时，更新该用户所有注册客户端的时间戳，下一次同步时将以该时间戳为准，而该二元组的时间戳将在一次成功同步后重新置零，从而避免重复的数据检查。

收到客户端请求后，服务端将对请求进行处理。不同的同步请求采用不同方法进行处理，处理过程如下：

身份验证。身份验证包含两方面内容，首先是用户身份验证，即该请求是否为合法用户的同步请求，其次是用户权限认证，即该用户的请求操作是否在其权限范围内。对客户端请求的认证由权限管理器完成，因此权限管理器为服务器端数据安全的保障，如附图1所示。

通过身份验证后，对请求参数进行检查，这里主要是指对同步请求的时间戳的检查。服务器端对每个(user, client)二元组保存了一个Last时间戳，用以标识该用户/客户端的最后一次正常完成的同步请求的时间。如果请求参数中不存在Last时间戳，但服务器端存在，则表示上一次服务器反馈未得到客户端确认，该次请求无效，返回错误并捎带上次同步请求时间戳；如果请求中包含上一次成功请求时间戳，则对比服务器保存的上一次成功同步时间戳与请求中的上一次成功时间戳，若一致，则确认完成，否则返回错误。客户端同步日志管理器通过对同步日志的时序保证，确定每一次都在前一次同步完成操作并得到对方确认后，才进行下一次同步，在时序控制这一概念上，客户端的同步日志管理器与服务端的时间戳管理器有着类似的功能，如附图1所示。

处理同步请求。以层序同步策略为例，服务检查请求中的节点ID与节点最后更改时间戳，如果与服务器相应节点的时间戳一致，则表示数据自上一次更新后未发生改变，返回数据未改变，并在参数中附加该次请求的Next时间戳，标识该次同步请求已完成。如果服务器对应节点的时间戳大于（或者晚于）客户端节点的最后更新时间戳，表示该节点自上次更新后发生了改变，此时选择该节点信息（包含节点ID、节点数据、节点最后更新时间戳）以及该节点的所有子节点的节点信息（节点ID以及最后更新时间戳，不包含节点数据）并返回给客户端，状态为数据已更改。发送反馈请求后，将服务端对应的Last时间戳更新为该次请求的Next时间戳，用于下一次请求的确认。

步骤四：客户端确认同步

客户端收到服务器返回结果后对返回结果中的Next时间戳与发送的Next时间戳进行对比，如果两者一致，表示该次同步已经完成，更新同步日志中该次同步的状态，标识为“completed”或者已完成，并将上一条以完成的同步日志状态标识为“confirmed”（返回结果正常表示请求中的捎带确认时间戳正常，否则服务端返回信息将为异常）或者已确认。重复步骤一，对服务端的反馈在下一次同步请求时捎带确认。如果请求为增加节点请求，则服务器返回结果中将包含该节点的GUID，此时需要将本地缓存数据中的LUID更新为GUID，从而完成树型节点的增加。

另外，上述步骤中的时间戳包含两种，一种为数据节点的最后访问时间戳，另一种为标识每一次同步过程的时间戳。前者对于所有数据节点，都必须统一采用服务器的时间，而对于后者，则可采用对应的客户端的本地时间。

总之，以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所作的均等变化与修饰，皆应属本发明专利的涵盖范围。

Claims

1.一种基于时间戳的树型结构数据同步方法，包括数据中心服务器集群和客户端，数据中心服务器集群包括多个服务器，数据中心服务器集群和客户端采用星型拓扑结构，包括以下具体步骤：

其中，客户端通过以下步骤确定同步时间窗口：

2.3）根据以下公式计算并重新确定?t，确定下一个同步时间窗口：

Figure 2013102228982100001DEST_PATH_IMAGE001

，，其中u为预设值，k为常量；

2.4）间隔时间?t届满时，重复步骤2.1。

2.根据权利要求1所述的基于时间戳的树型结构数据同步方法，其特征在于，所述步骤2还包括以下的同步策略：层序同步策略、增量同步策略、慢同步策略和刷新同步策略。

3.根据权利要求2所述的基于时间戳的树型结构数据同步方法，其特征在于，客户端登录服务器后检查服务器更新并执行层序同步策略；客户端发生数据改变时，客户端改变同步日志并执行增量同步策略；当客户端在执行增量同步策略的过程中发生同步失败、网络条件改善或者用户端主动请求时执行慢同步策略；当层序同步策略、增量同步策略和慢同步策略均失败时，执行刷新同步策略。

4.根据权利要求2所述的基于时间戳的树型结构数据同步方法，其特征在于，执行层序同步策略、增量同步策略和慢同步策略时还包括以下步骤：

5.根据权利要求1所述的基于时间戳的树型结构数据同步方法，其特征在于，所述步骤3还包括以下步骤：数据中心服务器集群的时间戳管理器生成双重时间戳以保证客户端对节点数据访问的时效性，双重时间戳包括节点本身的时间戳和用户授权访问范围的时间戳，其中，节点本身的时间戳标识了节点的最后修改时间，服务器存储的每个节点都有相应的时间戳，每次对节点的修改或者访问都将更新该节点及其父节点的时间戳；用户授权访问范围的时间戳标识用户的数据访问范围的变化情况，每一个(user, client)二元组都设定有一个用户授权访问范围的时间戳，当客户端首次注册时，该时间戳被预设为0，客户端进行同步时，将节点的时间戳与客户端时间戳的较大值作为最终的时间戳；当用户权限范围发生改变时，更新该用户所有注册客户端的时间戳，下一次进行同步时将以该时间戳为准，而二元组的时间戳将在一次成功同步后重新置零，从而避免重复的数据检查。