CN101005428A - 一种检测与解决数据同步冲突的实现方法 - Google Patents
一种检测与解决数据同步冲突的实现方法 Download PDFInfo
- Publication number
- CN101005428A CN101005428A CNA2006100985899A CN200610098589A CN101005428A CN 101005428 A CN101005428 A CN 101005428A CN A2006100985899 A CNA2006100985899 A CN A2006100985899A CN 200610098589 A CN200610098589 A CN 200610098589A CN 101005428 A CN101005428 A CN 101005428A
- Authority
- CN
- China
- Prior art keywords
- server end
- client
- clauses
- conflict
- subclauses
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/0004—Initialisation of the receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
Abstract
本发明所充分公开的是一种检测与解决数据同步冲突的实现方法,客户端与服务器端预先检测数据同步的冲突,并根据所述的冲突检测数据获得冲突仲裁结果;所述客户端与所述服务器端根据冲突仲裁结果进行数据同步。应用本发明方案,可以在客户端与服务器数据同步之前先对需要同步的数据进行冲突检测,可以准确地判断出哪些数据需要传输,哪些数据不需要传输,从而可以缩短同步时间,降低了网络流量。
Description
技术领域
本发明涉及数据同步技术,特别涉及一种检测与解决数据同步冲突的实现方法。
背景技术
为了制订可以在多个平台及网络之间实现个人信息与企业内数据同步的标准规格,于2000年2月份创建了业界团体SyncML iniative。后来SyncML规范移交到了OMA DS工作组(Open Mobile Alliance,Data Synchronization WorkGroup)。开发SyncML的目的在于,使终端用户、设备开发商、基础构件开发商、数据提供商、应用软件开发商以及服务提供商协同工作,真正实现使用任何终端设备均可随时随地访问任何网络数据。
SyncML的典型应用是在移动设备和网络服务之间的数据同步。除此之外,SyncML还可用于对等的数据同步,如两台PC之间。也就是说,两台PC中的任何一台既可以作为客户端,也可以作为服务器,客户端可以主动向服务器发起同步,而服务器也可以主动向客户端发起同步。
客户端和服务器之间进行数据同步的流程为:经过同步初始化阶段的参数协商以后,客户端和服务器互相发送各自改变的数据,以保证双方数据的同步。
现有技术中,客户端和服务器进行数据同步的类型有很多,同步类型如表一所示:
同步类型 | 描述信息 |
双向同步(Two-waysync) | 双向同步是通常所使用的一种同步方式。采用该方式,同步客户端和服务器端相互仅交换彼此设备中的数据修改信息,但是未修改的不交换。客户端首先发送其修改信息。 |
慢同步(Slow | 慢同步是双向同步的一种特殊类型,不同之处在于必须对数 |
sync) | 据进行逐条、逐个字段的进行比较处理。既当同步时,客户端必须把本地数据库中的所有数据都发送到服务器端,然后服务器端对用户的客户端数据和服务器端数据进行逐个字段的同步分析。 |
客户端单向同步(One-way syncfrom client only) | 客户端单向同步是一种单边方式的同步。只有客户端发送其数据修改信息到服务器,而服务器并不把服务器端的修改信息发给客户端。 |
客户端刷新(Refresh syncfrom client only) | 客户端刷新也是一种单边方式的同步。客户端把本地数据库中的所有数据都发送到服务器端,服务器用客户端的数据来覆盖服务器数据库中的所有数据。即服务器中的数据和客户端的完全一致,不多、不少、也没有不同的记录。 |
服务端单向同步(One-way syncfrom server only) | 服务端单向同步和客户端单向同步类似。只有服务器发送其数据修改信息到客户端,而客户端并不把它的修改信息发给服务器。 |
服务端刷新(Refresh syncfrom server only) | 服务端刷新和客户端刷新类似。服务器把数据库中用户的所有数据都发送到用户客户端,客户端用服务器的数据来覆盖客户端数据库中的所有数据。即客户端中的数据和服务器的完全一致,不多、不少、也没有不同的记录。 |
服务端通知同步(Server AlertedSync) | 服务端通知同步是指由服务器首先提醒客户端来执行同步操作。即由服务器来告诉客户端开始一个特定类型的同步操作。仅仅是服务器通知终端,要求其发起某种同步,后续同步流程可能为以上的同步方式,但是慢同步除外。 |
表一
现有技术中,同步一般分为三个阶段:同步初始化阶段、同步阶段和同步完成阶段。下面仅以双向同步来说明数据同步的过程。
图1是现有技术中双向同步的消息流示意图。
同步初始化阶段,如图1中标出的Pkg#1和Pkg#2。
在同步初始化阶段系统主要完成身份鉴权、需要同步的数据库的协商、同步能力的协商,例如支持同步哪些数据、支持哪些同步类型等。
现有技术中使用消息包的原因是:这种交互过程可能需要持续多次才能完成,但是在逻辑上只有一来一回两种消息。
同步阶段,如图1所表示出的Pkg#3和Pkg#4。客户端和服务器根据数据的状态如新增Add、更新Relpace、删除Delete、移动Move等命令将发生改变的数据通过上述操作命令的方式发送到服务器,服务器按照这些命令进行相同的操作来达到同步的目的;同时服务器也将其发生改变的数据通过操作命令的方式发送给客户端。同步完成阶段如图1标出的Pkg#5和Pkg#6所示,客户端和服务器端互相确认同步完成。
现有技术中的系统包括:数据同步客户端,它通常是一个PC软件、手机或PDA等智能终端。数据同步客户端(Data Synchronization Client)包含一个客户端数据库,用来存储用户所需的数据。这些数据包括:通讯录、日程、便笺、短信、电子邮件等。这些数据均有标准规范定义其格式,各种数据具体的格式如表二所示。客户端可以将数据转换成标准的格式发送给服务器,服务器处理后可保存入自己的数据库中。
数据类型 | Content Type | Media Type |
通讯录 | Contact | text/x-vcard or text/vcard |
日程 | Calendar | text/x-vcalendar or text/calendar |
便笺 | Memos | text/plain |
任务(格式与日程相同) | Tasks | text/x-vcalendar or text/calendar |
电子邮件 | message/rfc822 | |
application/vnd.omads-email | ||
短消息 | Message(SMSetc.) | |
文件 | File(images,music,movices,application) | application/vnd.omads-file |
表二
同步服务器可接收来自Data Sync Client的数据同步消息和同步命令,并能向同步客户端发送同步消息。这个设备可以是一个网络服务器或是一个个人计算机。数据同步服务器(Data Synchronization Server)包含了一个服务器端数据库(Server Database),用来存放服务器上的数据。
现有技术中的客户端和服务器端数据存储如表三和表四所示。
LUID | 数据项 |
11 | 小汽车 |
22 | 单车 |
33 | 卡车 |
44 | 鞋子 |
表三
GUID | 数据项 |
1010101 | 小汽车 |
2121212 | 单车 |
3232323 | 卡车 |
4343434 | 鞋子 |
表四
客户端使用LUID(Local Unique Identifier)来唯一标识一条数据,这个LUID可以是针对一种类型数据唯一,例如通讯簿内,也可以是在终端上唯一。服务器端使用GUID(Global Unique Identifer)来唯一表示一条数据,其唯一性与LUID相同。由于终端能力受限,LUID长度可能比较短,服务器端GUID长度则比较长,所以,在服务器端需要维护一个LUID和GUID之间的映射关系表。客户端和服务器端双方进行的操作都会导致相应记录条目状态的变更,双方根据条目状态来确定发送什么操作命令。所述的LUID-GUID的映射关系表如表五所示:
GUID | LUID |
1010101 | 11 |
2121212 | 22 |
3232323 | 33 |
4343434 | 44 |
表五
现有技术中的客户端发送给服务器的具体操作包括:
增加操作(<Add>),客户端将生成的LUID以及数据发送给服务器端,服务器完成处理后为其生成GUID,并保存<LUID-GUID>的映射关系;
更新操作(<Replace>),将LUID和数据发送给服务器进行更新;
删除操作(<Delete>),只需要将LUID发送给服务器,服务器根据映射关系找到GUID对应数据进行更新;
移动(<Move>),客户端指明被移动的条目的LUID,以及目的地的LUID,服务器进行相应处理。
现有技术中的服务器端发送给客户端的具体操作包括:
增加操作(<Add>),服务器将生成的GUID以及数据发送给服务器端,客户端完成处理后返回LUID给服务器,有服务器保存<LUID-GUID>的映射关系;
更新操作(<Replace>),将LUID和数据发送给客户端进行更新;
删除操作(<Delete>),只需要将LUID发送给客户端。
移动(<Move>),服务器指明被移动的条目的LUID,以及目的地的LUID,客户端进行相应处理。
其中,操作命令的交互,是在同步阶段;映射关系的发送是在同步完成阶段。
在现有技术数据同步冲突和解决有机制中,如果客户端和服务器端数据库对同一个条目进行了不同的修改,称为冲突。例如,客户端和服务器端对同一个vCard数据条目进行了修改。现有协议中,缺少完善的冲突检测机制和冲突解决策略:
(1)同步阶段客户端将会等待同步的数据全部发送到服务器端,而客户端的这些修改,可能和服务器端的修改产生冲突,如果最终的结果是服务器端的修改生效,则服务器端会将其数据下发给客户端,此时客户端发送的数据则增加了网络流量,延长了同步时间;特别是在同步大对象时这种缺点尤其明显,比如客户端需要发送多个较大的音乐文件。
(2)现有技术中,无法做到字段级别的冲突检测与解决。例如,客户端和服务器端修改了同一条vCard中的“国家”字段;
(3)现有技术中,冲突检测机制不完善,例如,客户端修改了vCard中的“国家”字段,服务器端修改了“街道”字段,这种其实不冲突的,同步时可以将双方的结果合并,但是现有协议中认为是冲突的。现有技术中仅根据修改状态来判断双方是冲突的,最终无法将客户端和服务器的修改合并,仅修改一个字段也要传递所有vCard数据,增加了网络流量。
发明内容
有鉴于此,本发明的主要目的在于提供一种检测与解决数据同步冲突的实现方法方法,可以在数据同步之前检测出冲突,并根据仲裁策略解决冲突,达到节省同步时间,降低了网络流量的目的。
为了达到上述目的,本发明提出的技术方案为:
一种检测与解决数据同步冲突的实现方法,包括以下步骤:
A、客户端与服务器端检测数据同步的冲突,并根据检测的冲突检测数据获得冲突仲裁结果;
B、客户端与服务器端根据获得的冲突仲裁结果进行数据同步。
较佳地,所述步骤A包括:
A1、客户端向服务器端发送冲突检测数据;
A2、服务器端根据接收到的冲突检测数据进行冲突检测,并根据预先配置的冲突仲裁策略获得冲突仲裁结果。
较佳地,所述步骤A2和步骤B之间进一步包括:
A3、服务器端向客户端发送获得的冲突仲裁结果。
较佳地,所述冲突检测数据包括客户端条目的条目标识,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AX1、服务器端接收冲突检测数据,并提取出条目标识;
AX2、服务器端根据提取出的条目标识查询自身数据库,确定与所述条目标识对应的服务器端的条目,再根据确定的服务器端条目的修改状态信息检测出冲突。
较佳地,所述冲突检测数据还包括客户端条目的条目修改状态信息,所述步骤AX1进一步包括:服务器端从冲突检测数据中提取出条目修改状态信息;
步骤AX2所述根据条目的修改状态信息检测出冲突的方法为:
服务器端将提取的条目修改状态信息与自身相应条目的修改状态信息进行对比,检测出冲突。
较佳地,所述冲突检测数据包括客户端条目的条目标识和修改字段标识,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AY1、服务器端接收冲突检测数据,提取出条目标识和修改字段标识;
AY2、服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段,然后根据服务器端字段的字段修改状态信息检测出冲突。
较佳地,所述冲突检测数据还包括客户端条目的修改字段状态信息或字段校验和,所述步骤AY1进一步包括:服务器端从冲突检测数据中提取修改字段状态信息或字段校验和;
步骤AY2所述根据服务器端字段的字段修改状态信息检测出冲突的方法为:
服务器端将提取的修改字段状态信息和自身相应字段的修改状态信息进行对比,检测出冲突;或者,
服务器端将提取的字段校验和与自身相应字段的字段校验和进行对比,检测出冲突。
较佳地,所述冲突检测数据包括客户端的条目标识和条目指纹,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AZ1、服务器端接收冲突检测数据,并提取出条目标识和条目指纹;
AZ2、服务器端根据提取出的条目标识在自身数据库中确定与所述条目标识对应的条目,再将提取的条目指纹与自身相应条目的条目指纹进行对比,检测出冲突。
较佳地,所述条目指纹为:
条目的时间戳、摘要值、锚值或版本号。
较佳地,所述客户端向服务器端发送冲突检测数据的方法为:客户端通过新增的同步命令或扩充的同步命令将冲突检测数据发送给服务器。
较佳地,所述服务器端向客户端发送冲突仲裁结果的方法为:服务器端通过新增的同步命令或扩充的同步命令将冲突仲裁结果发送给客户端。
较佳地,如果客户端与服务器端修改了同一条目的不同字段,则该方法进一步包括:
所述服务器端在冲突检测时将判定为不冲突,并在数据同步之后将服务器端修改的条目与客户端修改的条目进行合并。
较佳地,所述步骤A之前进一步包括:
客户端与服务器端协商是否进行冲突检测。
较佳地,在数据同步协议中增加先解决冲突的同步类型状态码,或增加服务器通知的同步类型状态码,所述客户端与所述服务器端协商的方法为:
X1、所述客户端向所述服务器发送初始化请求;
X2、所述服务器端判断是否同意所述初始化请求中指示的同步类型,如果不同意,则所述客户端与所述服务器端根据配置的同步类型的冲突解决策略,确定同步类型并进入步骤X3;如果同意,则转步骤X3;
X3、所述服务器端判断所述同步类型是否是现有的同步类型,如果是,则按现有的同步流程进行同步,再退出本流程;否则,转步骤A。
较佳地,所述先解决冲突的同步类型状态码为:
先解决冲突且后续同步为双向同步的同步类型状态码;
或者为先解决冲突且后续同步为慢同步的同步类型状态码;
或者为先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码;
或者为先解决冲突且后续同步为客户端的刷新同步的同步类型状态码;
或者为先解决冲突且后续同步为服务器端的单向同步的同步类型状态码;
或者为,增加先解决冲突,且后续同步为服务器端的刷新同步的同步类型状态码。
较佳地,所述服务器通知的同步类型状态码为:
服务器端通知,先解决冲突且后续同步为双向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为慢同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为客户端的单向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为客户端的刷新同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为服务器端的单向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为服务器端的刷新同步的同步类型状态码;
所述步骤X1之前进一步包括:
服务器端向客户端发送协商通知消息。
较佳地,配置一个先解决冲突的参数,所述客户端与所述服务器端协商的方法为:
Y1、客户端向服务器端发送初始化请求;
Y2、所述服务器端判断所述初始化请求中是否包含所述先解决冲突的参数,若没有,则按现有的同步流程进行同步,再退出本流程;否则转步骤Y3;
Y3、所述服务器端判断是否同意所述初始化请求中的同步类型以及所述先解决冲突的参数,若同意,则转步骤A;否则转步骤Y4;
Y4、同步双方协商,确定进行同步的同步类型以及同步流程,并按照新确定的同步流程进行同步,再退出本流程。
较佳地,所述客户端与所述服务器端协商的方法为:
客户端向服务器端发送初始化请求,服务器端根据事先配置的协商原则或冲突仲裁原则判断是否进行冲突检测,并向客户端返回协商结果;客户端根据协商结果确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
较佳地,所述初始化请求包括请求冲突检测的信息。
较佳地,所述客户端与所述服务器端协商的方法为:
服务器端向客户端发送协商通知命令,客户端根据协商通知命令确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
较佳地,所述客户端与所述服务器端协商的方法为:
服务器将仲裁原则发送给客户端,客户端直接根据仲裁原则确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
较佳地,所述预先配置的仲裁策略为:
服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略。
综上所述,本发明提出一种检测与解决数据同步冲突的实现方法,由于在数据同步之前,客户端和服务器端对需要进行同步的数据进行了冲突检测,如果有冲突,则用冲突仲裁原则对冲突进行仲裁,可以准确地判断出哪些数据需要传输,哪些数据不需要传输,从而可以节省同步时间,降低了网络流量。
另外,由于可以在数据同步冲突检测之前增加一个客户端和服务器端之间协商是否进行冲突检测的步骤,从而可以增加客户端和服务器端选择是否进行冲突检测的灵活性。
附图说明
图1是现有技术的双向数据同步流程的示意图;
图2是本发明方案的流程图;
图3是应用本发明方案的实施例一的流程图;
图4是应用本发明方案的实施例二的流程图;
图5是应用本发明方案的实施例三的流程图;
图6是应用本发明方案的实施例四的流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图及具体实施例对本发明作进一步地详细描述。
本发明提供的是一种检测与解决数据同步冲突的实现方法,能够最大限度的满足用户需要,缩短了数据同步的时间,降低了网络流量。
本发明的核心思想是:客户端与所述服务器端预先进行数据同步冲突的检测,再对冲突进行仲裁,获得仲裁结果,然后根据仲裁结果进行数据同步。
图2是本发明的流程图。如图2所示,本发明检测和解决数据同步冲突的实现方法的步骤包括:
步骤201:客户端与服务器端检测数据同步的冲突,并根据冲突检测数据获得冲突仲裁结果。
本发明中,客户端与服务器端检测数据同步的冲突,并获得冲突仲裁结果的方法为:
客户端向服务器端发送冲突检测数据;服务器端根据接收到的冲突检测数据进行冲突检测,并根据预先配置的冲突仲裁策略获得冲突仲裁结果。
这里所述的服务器端进行冲突检测的方法有很多,比如:
如果冲突检测数据包括条目标识,则冲突检测的方法为:服务器端接收冲突检测数据,并提取出条目标识;服务器端根据提取出的条目标识查询自身数据库,确定与所述条目标识对应的服务器端的条目,再根据确定的服务器端条目的修改状态信息检测出冲突。
在上述方法中,如果客户端修改了某条目,则服务器只要在自身数据库中确定相应的条目也被修改过,就可以直接判断为发生了冲突。
如果冲突检测数据包括条目标识和条目修改状态信息,则冲突检测的方法为:服务器端接收冲突检测数据,提取出条目标识和条目修改状态信息;服务器端根据提取出的条目标识查询自身数据库,确定与所述条目标识对应的服务器端的条目;服务器端再将提取的条目修改状态信息与自身相应条目的修改状态信息进行对比,检测出冲突。
在上述方法中,如果客户端修改了某条目,并用条目修改状态信息标识修改的类型,如“删除”、“更新”等,则服务器端可以将客户端修改的状态信息与自身的修改状态进行比较,判断是否发生了冲突。在这种情况下,可以事先为服务器配置一个冲突检测的原则。比如:客户端和服务器端都对某条目进行了更新,则判断为发生了冲突。又比如:客户端和服务器端都对某条目进行了删除,则判断为不冲突。当然,这里所述的冲突检测原则可以由应用本发明方案的用户自行确定,此处不再赘述。
如果冲突检测数据包括条目标识和修改字段标识,则冲突检测的方法为:服务器端接收冲突检测数据,提取出条目标识和修改字段标识;服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段,然后根据服务器端字段的字段修改状态信息检测出冲突。
在上述方法中,如果客户端修改了某条目的某字段,则服务器只要在自身数据库中确定相应条目的字段也被修改过,就可以直接判断为发生了冲突。
如果冲突检测数据包括条目标识、修改字段标识和修改字段状态信息,则冲突检测的方法为:服务器端接收冲突检测数据,提取出条目标识、修改字段标识和修改字段状态信息;服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段;服务器端将提取的修改字段状态信息和自身相应字段的修改状态信息进行对比,检测出冲突。
在上述方法中,如果客户端修改了某条目中某字段,并用字段修改状态信息标识修改的类型,如“删除”、“更新”等,则服务器端可以将客户端修改的状态信息与自身的修改状态进行比较,判断是否发生了冲突。在这种情况下,也可以事先为服务器配置一个冲突检测的原则。比如:客户端和服务器端都对某条目中同一个字段进行了更新,则判断为发生了冲突。又比如:客户端和服务器端对某条目中不同字段进行了修改,则判断不冲突。
如果冲突检测数据包括条目标识、修改字段标识和字段校验和,则冲突检测的方法为:服务器端接收冲突检测数据,提取出条目标识、修改字段标识和字段校验和;服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段;服务器端将提取的字段校验和与自身相应字段的字段校验和进行对比,检测出冲突。
上述方案中,需要事先为每一个字段的设置一个字段校验和,该字段校验和可以通过Hash算法获得,并可以作为该字段唯一的标识。当字段被修改后,该字段的字段校验和也会相应的变化。所以,服务器端可以直接通过字段校验和来确定是否发生了修改,并且其修改是否相同。如果字段校验和相同,则判断为不冲突;否则,判断为冲突。
如果冲突检测数据包括条目标识和条目指纹,则冲突检测的方法为:服务器端接收冲突检测数据,提取出条目标识和条目指纹;服务器端根据提取出的条目标识在自身数据库中确定与所述条目标识对应的条目,再将提取的条目指纹与自身相应条目的条目指纹进行对比,检测出冲突。
上述方案中,所述的条目指纹是条目的唯一标识,可以为条目的时间戳、摘要值、锚值或版本号,其中锚值即现有技术中的Anchor值。服务器端可以直接比较条目指纹是否相同,如果相同,则判断为不冲突;否则,判断为冲突。
实际应用中,冲突检测数据还可以包括条目标识与条目修改状态信息、字段标识、字段修改状态信息、条目指纹等的组合,至于组合的方式可以由应用本发明方案的用户自行确定,此处不再一一列举。
实际应用中,如果客户端和服务器端是对等关系,服务器端也可以向客户端发送冲突检测数据,由客户端对冲突检测数据进行冲突检测,并根据冲突检测数据获得冲突仲裁结果。此时,客户端充当的是服务器端的角色,而服务器端则充当客户端的角色。
步骤202:客户端与服务器端根据冲突仲裁结果进行数据同步。
本发明中,步骤201与步骤202之间还可以增加由服务器端将冲突仲裁结果返回给客户端的步骤,也可以没有服务器端将冲突仲裁结果返回给客户端的步骤。比如:如果客户端和服务器端之间采用服务器到客户端的单向同步的方式进行数据同步,则当服务器端获得冲突仲裁结果之后,可以由服务器端直接根据冲突仲裁结果将需要同步的数据发送给客户端,实现数据同步。如果客户端和服务器端之间采用双向同步的方式进行数据同步,则当服务器端获得冲突仲裁结果之后,服务器端还需要将冲突仲裁结果返回给客户端,之后,客户端和服务器再根据冲突仲裁结果各自将需要同步的数据发送给对方。
实际应用中,当服务器端确定存在冲突时,需要根据预先配置的仲裁策略对冲突进行仲裁。这里所述的仲裁策略可以由应用本发明方案的用户自行确定。比如:可配置服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略。也可以根据实际应用引入其他的仲裁策略,仲裁策略的改变不应理解为对本发明的限制;
如果采用服务器端赢的仲裁策略,一旦确定发生冲突,客户端不必将条目或字段上传给服务器,只需服务器端将自身数据库中该条目或字段同步给客户端即可,可以降低网络流量。
如果采用客户端赢的仲裁策略,一旦确定发生冲突,客户端将把自身数据库中条目或字段上传给服务器端,服务器端无需将该条目或字段下传给客户端,同样可以降低网络流量。
如果采用互相忽略的仲裁策略,一旦确定发生冲突,客户端和服务器都不需要向对方发送数据,同样可以降低网络流量。
如果用户需求的仲裁策略,一旦确定发生冲突,可以由用户自行确定以服务器端还是以客户端的数据为标准进行数据同步。
如果采用时间戳仲裁策略,一旦确定某数据对象冲突,可以由修改数据的时间戳确定以服务器端还是以客户端的数据对象为标准进行数据同步。
实际应用中,本发明中客户端和服务器端检测数据同步的冲突可以在同步初始化阶段内完成,也可以在初始化阶段和同步阶段之间完成,也就是说,只要在进行同步阶段之前完成即可。
为了更好地说明本发明方案,下面用一个较佳实施例说明检测与解决数据同步冲突地实现方法。
实施例一
本实施例中,客户端数据库的存储状态如表六所示:
LUID | First Name | Last Name | Telephone |
12 | John | Done | +650 5050403 |
13 | Mike | White | +13292662203 |
14 | Vincent | Brown | +14694322045 |
15 | Linyi | Pob | +12341122304 |
16 | Guo | Da | +11223344556 |
表六
服务器端数据库的存储状态如表七所示:
GUID | First Name | Last Name | telephone |
1012 | John | Done | +16505050403 |
1013 | Mike | White | +13292662203 |
1014 | Vincent | Brown | +14694322045 |
1015 | Linyi | Pob | +12341122304 |
1016 | Guo | Da | +11223344556 |
表七
而此时服务器端存储的映射表如下:
LUID | GUID |
12 | 1012 |
13 | 1013 |
14 | 1014 |
15 | 1015 |
16 | 1016 |
表八
客户端修改LUID=12条目的First Name,并且删除了LUID=13的条目,同时把LUID=15的数据条目从根目录移动到“好友”目录,还修改了LUID=16的数据条目的Last Name。修改之后的数据库如表九所示:
LUID | FirstName | LastName | telephone | 状态 |
12 | Kang | Done | +16505050403 | Replace(FirstName) |
13 | Mike | White | +13292662203 | Delete |
14 | Vincent | Brown | +14694322045 | NoChange |
15 | Linyi | Pob | +12341122304 | Move(“好友”) |
16 | Guo | Daa | +11223344556 | Replace(LastName) |
表九
服务器端删除了GUID=1012的条目,并且修改了GUID=1013的条目的Last Name,同时把GUID=1015的条目从根目录移动到“同事”目录。修改之后,如表十所示:
GUID | FirstName | LastName | telephone | 状态 |
1012 | John | Done | +16505050403 | Delete |
1013 | Mike | Smith | +13292662203 | Replace |
1014 | Vincent | Brown | +14694322045 | NoChange |
1015 | Linyi | Pob | +12341122304 | Move(“同事”) |
1016 | Guo | 十Da | +11223344556 | NoChange |
表十
另外,本实施例中,服务器可以根据预先设置的冲突原则判断是否发生冲突。
这里所述的冲突原则可以如表十一所示。
数据 | 客户端修改状态 | 服务器修改状态 | 检测结果 |
同一条目 | 修改 | 修改 | 冲突 |
同一条目 | 删除 | 修改 | 冲突 |
同一条目 | 修改 | 删除 | 冲突 |
同一条目的同一域或字段 | 修改域1 | 修改域1 | 冲突 |
同一条目不同域或字段 | 修改域1 | 修改域2 | 不冲突,合并 |
同一条目 | 移动 | 修改 | 冲突 |
同一条目 | 移动 | 删除 | 冲突 |
同一条目 | 移动 | 移动 | 如果移动到不同的目录,则冲突;如果移动到相同的目录,则不冲突。 |
表十一
实际应用中,还可能存在其它检测冲突的原则,此时不再一一列举。
图3是本实施例的流程图。如图3所示,本实施例实现检测与解决数据同步冲突的实现方法包括以下步骤:
步骤301:客户端向服务器端发送所述冲突检测数据。
本实施例中,客户端对条目标识LUID=12的条目、LUID=13的条目、LUID=15,LUID=16的条目分别进行了修改,需要将相应的条目标识和条目修改状态信息作为冲突检测数据发送给服务器端。
实际应用中,客户端向服务器端发送冲突检测数据的方式很多,比如:可以通过新增的同步命令或扩充的同步命令将冲突检测数据发送给服务器。
如果通过新增的同步命令,该命令可以表示为XML格式。例如可给该命令命名为<ConflictDetect>,该命令中携带的冲突检测数据至少包含数据对象的标识和数据对象的修改状态,还可进一步还包括时间戳、修改字段名称、修改字段状态与对修改数据生成的校验和之中的一个或几个的组合。上述的冲突检测数据可以包含在冲突检测命令的一个标签中,或包含在多个标签中。以下给出新增的同步命令的XML格式的几个实施例。
例如上述的同步命令可以采用以下的格式组织,即将数据对象标识根据它们的修改状态的不同包含在不同的元素中,如下所示:
<ConflictDetect>
<命令编号>5</命令编号>
<修改数据的标识>11,13,14</修改数据的标识>
<删除数据的标识>15,16</删除数据的标识>
</ConflictDetect>
上述的命令也可以以以下的格式来组织,即数据对象标识和数据修改状态统一包含在一个元素中,如下所示:
<ConflictDetect>
<命令编号>5</命令编号>
<数据项>
<数据的标识>11</修改数据的标识>
<修改状态>删除</修改状态>
</数据项>
<数据项>
<数据的标识>12</修改数据的标识>
<修改状态>更新</修改状态>
</数据项>
</ConflictDetect>
或也可以采用以下的形式组织,即将数据对象标识根据它们的修改状态的不同包含在不同的元素中,一个标识包含在一个元素中,如下所示:
<ConflictDetect>
<命令编号>5</命令编号>
<修改数据的标识>
<标识>11</标识>
<标识>12</标识>
</修改数据的标识>
</ConflictDetect>
无论上述的命令以何种格式组织,均在本发明保护范围内。
所述客户端向所述服务器发送冲突检测数据,也可以通过扩充现有的同步命令的含义来实现,例如扩充现有的<Alert>命令,或<Add>命令,或其他命令的含义,如:Replace命令等。
以下给出一种扩充<Alert>命令的含义来实现客户端发送冲突检测数据的实现方案。如果客户端在同步初始化阶段将冲突检测数据发送给服务器端,可以在初始化阶段中的<Alert>命令中携带冲突检测数据,其命令的形式可以为:
<Alert>
<命令编号>5</命令编号>
……
<修改数据的标识>
<标识>11</标识>
<标识>12</标识>
</修改数据的标识>
</Alert>
实际应用中,还可以在同步过程中定义一新的标签来实现,例如定义<ConflictDetect>用来表示冲突检测数据,定义该标签的DTD如下:
(CmdID,Cmd,Source,SoureParent?,Target,TargetParent?,Cred?,Data*)
其中加星号“*”,表示该标签可以出现0次或是多次,加“?”表示该标签可出现0次或是1次。
所述客户端发送<ConflictDetect>标签给所述服务器端,所述服务器端对比自己的修改,按照配置的策略解决冲突,并向所述客户端返回冲突解决的结果。例如:所述客户端对数据库中LUID=15的数据项的FN(First Name)和LN(Last Name)字段进行了修改,则所述客户端发送给所述服务器的冲突检测数据为:
<Conflict>
<CmdID>5</CmdID>
<Cmd>指示进行的操作为修改(Replace)</Cmd>
<Source><LocURI>指示被修改的数据项的LUID=15</LocURI></Source>
<Data>指示修改的字段为FN和LN</Data>
</Conflict>
其中,可以在<Data>标签中,利用现有规范中定义的CGI语法携带修改的字段。规范中的CGI语法是采用逻辑运算符来表示数据间的逻辑关系,例如“&AND;”表示的是逻辑与,“&OR;”表示逻辑或,其余的运算符如“&EQ;”,“&iEQ;”,“&NE;”,“&iNE;”,“&CON;”,“&iCON;”等等。
例如上述的修改,在<Data>标签中可用CGI语法表示为:
<Data>FN & AND;LN</Data>
服务器端对该命令返回的同步命令如下:
<Status>
<CmdID>4</CmdID>
<MsgRef>2<MsgRef><CmdRef>5</CmdRef><Cmd>Conflict</Cmd>
<Data>服务器对上述的Conflict标签返回状态码</Data>
</Status>
实际应用中,也可以扩充现有的标签定义,来表示冲突检测数据。
现有的SyncML中,所述客户端与所述服务器端通过<Status>标签对对方同步命令返回执行状态码。现有的<Status>标签的DTD为:
(CmdID,MsgRef,CmdRef,Cmd,TargetRef*,SourceRef*,Cred?,Chal?,Data,Item*)
为了实现“先解决冲突后同步”的思想,可以扩充规范中的<Status>的含义,在规范中对<Status>增添了一些可选元件,包括:(Source,SourceParent,Target,TargetParent),使现有的<Status>不但可以对对方的命令返回状态码,同时可以携带冲突检测数据。对<Status>命令的DTD的修改如下所示:
(CmdID,MsgRef*,CmdRef*,Cmd,Source?,SoureParent?,Target?,TargetParent?,TargetRef*,SourceRef*,Cred?,Chal?,Data*,Item*)
无论上述的命令以何种格式组织,均在本发明保护范围内。
步骤302:服务器端接收到冲突检测数据,提取出冲突检测数据中的条目标识和条目修改状态信息。
本实施例中,服务器端将接收到客户端的LUID=12、LUID=13、LUID=15、LUID=16四个条目的条目标识和条目修改状态信息,所述的条目修改状态信息依次为“更新”、“删除”、“移动”和“更新”;服务器端还会接收到LUID=12条目的First Name字段标识和字段修改状态信息,LUID=16的条目的Last Name字段标识和字段修改状态信息。
实际应用中,客户端还可以只向服务器端发送条目标识,或发送条目标识和字段标识等。至于客户端向服务器发送的冲突检测数据的内容与服务器端进行冲突检测的方法决定,并可以由应用本发明方案的用户自行确定,此处不再详细叙述。
另外,本实施例中,当服务器端根据接收到的客户端的条目标识查询自身数据库时,还需要通过表八中客户端条目标识和服务器端条目标识的映射关系来查询自身数据库。实际应用中,客户端条目标识和服务器端条目标识还可以直接对应,无需通过表八来进行映射。现有技术中的LUID和GUID的映射机制可能会改变,但是客户端和服务器端之间的数据仍然会存在对应关系,客户端和服务器需要根据标识找到对应的数据,映射机制的改变不应该理解为对本发明的限制。
步骤303:服务器端对比自身相应条目的修改状态信息,检测出冲突。
本实施例中,服务器端可以根据表十一所示的冲突原则对接收的来自客户端的冲突检测数据进行冲突检测。显然,冲突检测之后,服务器端将确定,LUID=12的条目不冲突,LUID=13和LUID=15的条目发生了冲突,需要进行冲突仲裁。
步骤304:服务器端按照预先配置的仲裁策略对冲突进行仲裁,获得冲突仲裁结果。
实际应用中,可以预先在服务器端配置仲裁策略,所述的仲裁策略可以为服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略等。当然,如果采用时间戳仲裁策略,还需要为每一个条目或每一个条目的字段设置时间戳,记录最后一次修改的时间,并通过步骤301发送给服务器端。
不管服务器端配置的是哪种仲裁策略,服务器端都可以为检测出的冲突确定一个仲裁结果,从而可以确定哪些条目需要由客户端上传给服务器端,哪些条目需要由服务器端发送给客户端。
比如:本实施例中,如果预先配置服务器端赢的仲裁策略,并且客户端和服务器采用双向同步方式,则服务器端的仲裁结果是:客户端无需上传条目标识LUID=1013和LUID=1015的条目的相关数据,只需由服务器将条目标识LUID=1013和LUID=1015的条目的相关数据发送给客户端即可。
步骤305:服务器端向客户端发送冲突仲裁结果。
本实施例中,服务器端可以通过新增的同步命令或扩充的同步命令将冲突仲裁结果发送给客户端,其方法与步骤301相似,
比如:服务器向客户端下发冲突仲裁结果通过新增的同步命令实现,该命令可以表示成XML语言,例如可命名为<ConflictResult>。所述客户端与所述的服务器可以约定该命令中仅携带需要客户端上传的数据的标识,或仅携带不需要客户端删除的数据项的标识,或返回所有进行冲突检测的数据的标识及其冲突仲裁结果等。以下给出几种<ConflictResult>命令的组织形式,无论该命令以何种形式组织,均在本发明的保护范围里。
在<ConflictResult>中仅返回需客户端上传的数据项的标识,该标识可以统一放在一个元素中或一个标识对应一个元素,如下所示:
<ConflictResult>
<命令编号>8</命令编号>
<需要上传的数据项标识>11,13,24</需要上传的数据项标识>
</ConflictResult>
也可在<ConflictResult>中返回返回所有进行冲突检测的数据的标识及其冲突仲裁结果,数据项的标识可以根据冲突仲裁的结果包含在不同的元素中,如下所示:
<ConflictResult>
<命令编号>8</命令编号>
<需要上传的数据项标识>11,12,13</需要上传的数据项的标识>
<不需要上传的数据项标识>14,15,16</需要上传的数据项的标识>
<合并的数据项标识>17</合并的数据项标识>
</ConflictResult>
所述的所述服务器向所述客户端发送冲突仲裁结果,也可以通过扩充现有的同步命令的含义来实现,例如扩充<Status>的含义,在现有的<Status>命令中携带上述的冲突仲裁结果。所述客户端与所述的服务器可以约定该命令中仅携带需要客户端上传的数据的标识,或仅携带不需要客户端删除的数据项的标识,或返回所有进行冲突检测的数据的标识及其冲突仲裁结果等。
以下给出一种扩充<Status>命令含义来携带冲突仲裁结果的实施方案,其中,<Status>命令是对携带冲突检测数据的命令进行的回复,如下所示:
<Status>
<命令编号>8</命令编号>
<回复命令的编号>7</回复命令的编号>
<回复命令的名称>携带冲突检测数据的命令</回复命令的名称>
……
<需上传的数据的标识>11,12,13</需上传的数据的标识>
</Status>
又比如:可以扩充现有的<Status>,其扩充方法如下所示:<Status>
<命令编号>8</命令编号>
<回复命令的编号>7</回复命令的编号>
<回复命令的名称>Alert(携带冲突检测数据的命令)</回复命令的名称>
......
<需上传的数据的标识>11</需上传的数据的标识>
</Status>
实际应用中,服务器端通过冲突仲裁结果通知客户端需要发送哪些条目,不需要发送哪些条目。如果某条目并未发生冲突,但仍然需要由客户端发送给服务器时,也可以通过冲突仲裁结果来通知客户端。比如:本实施例中,LUID=16未发生冲突,但为了达到双向同步的目的,仍然需要通知客户端上传LUID=16的条目的相关数据。
步骤306:客户端与服务器端根据冲突仲裁结果进行数据同步。
实际应用中,客户端和服务器端将根据事先在同步初始化阶段指定的方式进行数据同步,比如:双向同步方式、服务器单向同步方式、客户端单向同步方式等。
另外,实际应用中,本实施例中的步骤301~步骤305为可以在同步初始化阶段中进行,也可以在同步初始化阶段和同步阶段之间进行。如果在初始化阶段中进行,可以采用新增的同步命令实现步骤301和步骤305,也可以采用扩充现有的同步命令来实现步骤301和步骤305。如:可以通过初始化阶段中的<Alert>命令来发送冲突检测数据,通过<Status>返回冲突仲裁结果。
应用本实施例方案,可以在数据同步之前,先对需要同步的数据进行冲突检测,并进行冲突仲裁,再根据冲突仲裁结果进行数据同步,可以准确判断真正需要传输的数据,从而缩短同步时间,降低了网络流量。
实施例二
本实施例中,客户端数据库如表十二所示,服务器端数据库如表十三所示。
UID | First Name | Last Name | Telephone | 父目录 | Status |
11 | Kent | Niny | +16515050503 | 根目录 | - |
12 | John | Done | +16505050403 | 根目录 | - |
13 | Mike | White | +13292662203 | 根目录 | - |
14 | Vincent | Brown | +14694322045 | 根目录 | - |
15 | Linyi | Pob | +12341122304 | 根目录 | - |
16 | Katy | Len | +12341122308 | 根目录 | - |
表十二
UID | First Name | Lasr Name | Telephone | 父目录 | Status |
11 | Kent | Niny | +16515050503 | 根目录 | - |
12 | John | Jao | +16505050403 | 根目录 | - |
13 | Kite | Smith | +14694322045 | 根目录 | - |
14 | Vincent | Brown | +13292662203 | 根目录 | - |
15 | Liny | Pob | +12341122304 | 根目录 | - |
16 | Katy | Len | +12341122308 | 根目录 | - |
表十三
本实施例中,客户端的条目标识和服务器端的条目标识是相同的,可以直接对应,无需用映射表进行映射。客户端修改UID=11的条目的First Name,UID=12的条目的First Name,删除了UID=13的条目,把UID=15的数据条目从根目录移动到“好友”目录,并新增了UID=17的数据条目。修改之后,如表十四所示:
UID | First Name | Last Name | Telephone | 父目录 | 修改状态 |
11 | Kenty | Niny | +16515050503 | 根目录 | - |
12 | Kang | jao | +16505050403 | 根目录 | 修改 |
13 | Kite | Smith | +14694322045 | 根目录 | 删除 |
14 | Vincent | Brown | +13292662203 | 根目录 | - |
15 | Lin | Pob | +12341122304 | “好友” | 移动 |
16 | Katy | Len | +12341122308 | 根目录 | - |
17 | Helen | Merry | +12341122333 | 根目录 | 新增 |
表十四
服务器端修改了UID=12的条目的Last Name,修改了UID=13的条目的LastName,把UID=15的条目从根目录移动到“同事”目录,修改了UID=16的条目的Last Name,修改之后如表十五所示:
UID | First Name | LastName | Telephone | 父目录 | 修改状态 |
11 | Kent | Niny | +16515050503 | 根目录 | - |
12 | John | June | +16505050403 | 根目录 | 修改 |
13 | King | Smith | +14694322045 | 根目录 | 修改 |
14 | Vincent | Brown | +13292662203 | 根目录 | - |
15 | Liny | Pob | +12341122304 | “同事” | 移动 |
16 | Katy | Lenny | +12341122308 | 根目录 | 修改 |
表十五
本实施例中,不为条目中的字段设置字段标识和字段修改状态信息,只为条目本身设置条目标识和条目状态信息。
服务器可以根据预先设置的冲突原则判断是否发生冲突。这里所述的冲突原则可以如表十六所示。
数据 | 客户端修改状态 | 服务器修改状态 | 检测结果 |
同一条目 | 修改 | 修改 | 冲突 |
同一条目 | 删除 | 修改 | 冲突 |
同一条目 | 修改 | 删除 | 冲突 |
同一条目 | 移动 | 修改 | 冲突 |
同一条目 | 移动 | 删除 | 冲突 |
同一条目 | 移动 | 移动 | 冲突 |
表十六
图4是本实施例的流程图。如图4所示,本实施例实现检测与解决数据同步冲突的方法包括以下步骤:
步骤401:客户端和服务器端之间协商是否进行数据冲突检测,如果是,则继续执行步骤402;否则,退出本流程。
进行协商的目的在于,某些情况下是没有必要进行冲突检测的,避免不必要数据的发送。例如:如果服务器端仲裁策略为“客户端赢”,则对于冲突的情况,客户端数据是一定要发送给服务器覆盖服务器端数据的,那么发送冲突检测数据显得没有意义;另外,如果服务器端数据未进行过任何修改,则不会产生冲突,则也没有必要进行冲突检测。
实际应用中,客户端和服务器端进行协商的方法很多。比如,首先在初始化请求中配置一个先解决冲突的参数,再采用以下方法进行协商:
X1、客户端向服务器端发送初始化请求;
X2、服务器端判断初始化请求中是否包含先解决冲突的参数,若没有,则按现有的同步流程进行同步,再退出本流程;否则转步骤X3;
X3、服务器端判断是否同意初始化请求中的同步类型以及先解决冲突的参数,若同意,则转步骤402;否则转步骤X4;
X4、同步双方协商,确定进行同步的同步类型以及同步流程,并按照新确定的同步流程进行同步,再退出本流程。
可以在<Alert>命令中增加一个元素<GotoConflictDetect>来指明客户端请求进入冲突检测和仲裁阶段;
<Alert>
……
<GotoConflictDetect/>
</Alert>
或者可以在<Alert>命令中增加一个属性“GotoConflictDetect”来指明客户端请求进入冲突检测和仲裁阶段;
<Alert GotoConflictDetect=true........>
</Alert>
如果协商先解决冲突与协商同步类型是在同一个<Alert>里面,则可能的情况如表十七所示:
序号 | 描述 | 状态码 |
1 | 同意同步类型同意先解决冲突 | 217 |
2 | 同意同步类型不同意先解决冲突 | 218 |
3 | 不同意同步类型同意先解决冲突 | 219 |
4 | 不同意同步类型不同意先解决冲突 | 220 |
表十七
采用这种方案,需新增上述的4个状态码,由服务器通过<Status>命令携带这些状态码来表明协商结果;如果服务器不同意同步类型,双方可以重新协商同步类型。
如果先协商同步类型,后再通过一个新的<Alert>命令进一步的协商是否先解决冲突,则可能的情况有两种,如表十八所示:
序号 | 描述 | 状态码 |
1 | 同意先解决冲突 | 217 |
2 | 不同意先解决冲突 | 218 |
表十八
实际应用中,状态码的增加可能不同,但也在本发明的保护范围内;
实际应用中,客户端和服务器端还可以在数据同步协议中增加先解决冲突的同步类型状态码,或增加服务器通知的同步类型状态码,再采用以下的方法进行协商:
Y1、客户端向服务器发送初始化请求;
Y2、服务器端判断是否同意初始化请求中指示的同步类型,如果不同意,则客户端与所述服务器端根据配置的同步类型的冲突解决策略,确定同步类型并进入步骤Y3;如果同意,则转步骤Y3;
Y3、服务器端判断所述同步类型是否是现有的同步类型,如果是,则按现有的同步流程进行同步,再退出本流程;否则,转步骤402。
这里,所述的先解决冲突的同步类型状态码为:先解决冲突且后续为双向同步的同步类型状态码;或者为先解决冲突且后续为慢同步的同步类型状态码;或者为先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码;或者为先解决冲突且后续同步为所述客户端的刷新同步的同步类型状态码;或者为先解决冲突且后续同步为所述服务器端的单向同步的同步类型状态码;或者为,增加先解决冲突,且后续同步为所述服务器端的刷新同步的同步类型状态码。
所述服务器通知的同步类型状态码为:服务器端通知,先解决冲突且后续的为双向同步的同步类型状态码;或者为服务器端通知,先解决冲突且后续的为慢同步的同步类型状态码;或者为服务器端通知,先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码;或者为服务器端通知,先解决冲突且后续同步为所述客户端的刷新同步的同步类型状态码;或者为服务器端通知,先解决冲突且后续同步为所述服务器端的单向同步的同步类型状态码;或者为服务器端通知,先解决冲突且后续同步为所述服务器端的刷新同步的同步类型状态码。实际应用中,如果客户端和服务器端采用服务器通知的同步类型状态码进行协商,还需要在步骤Y1之前增加一个由服务器端向客户端发送协商通知消息的步骤。
实际应用中,客户端和服务器端进行协商的方法还可以为:
客户端向服务器端发送初始化请求,服务器端根据事先配置的协商原则或冲突仲裁原则判断是否进行冲突检测,并向客户端返回协商结果。当然,如果确定无需进行冲突检测,则可以按照现有技术进行同步处理过程;否则,执行步骤402。这里所述的初始化请求可以包括客户端请求进行冲突检测的信息,也可以不包括客户端请求进行冲突检测的信息。所述的协商原则可以由应用本发明方案的用户自行确定。比如:可以在服务器端将协商原则设置为无需进行冲突检测。另外,服务器端也可以根据仲裁原则来判断是否进行冲突检测,比如:服务器端配置的是服务器端赢的仲裁原则,则无需再进行冲突检测。
实际应用中,客户端和服务器端进行协商的方法还可以为:
服务器端向客户端发送协商通知命令,如果该协商通知命令通知无需进行冲突检测,则可以按照现有技术进行同步处理过程;否则,执行步骤402。这里,邮件通知可以由所述邮件服务器通过其它引擎下发,例如短消息、无线信息推送WAP Push、会话初始化协议信息SIP Message、多媒体短消息MMS等,或由所述服务器通过数据同步协议定义的通知下发,例如通过数据同步协议定义的通知命令<Alert>下发邮件通知。
实际应用中,客户端和服务器端进行协商的方法还可以为:
服务器将冲突仲裁原则发送给客户端,客户端直接根据冲突仲裁原则确定是否进行冲突检测。例如,如果配置的冲突仲裁原则是所述客户端赢的原则,即双方按照所述客户端的需求进行同步,那么将判定本次无需进行冲突检测,客户端需将数据上传到服务器端。这是因为服务器端将接收客户端的任何修改,如果发生冲突,服务器端也将按照客户端的需求进行修改。
所述服务器可以通过扩充现有的同步来向所述客户端返回是否进行冲突检测的结果或返回配置的冲突仲裁原则。例如在现有的<Status>命令增加一个标识,指示所述客户端需要进行冲突检测,或通过在<Status>标签中增加一个元素携带配置的冲突仲裁原则或标识冲突仲裁原则的状态码,由客户端判定是否进行冲突检测。
实际应用中,客户端和服务器端可以进行协商,也可以不进行协商。如果不进行协商时,可以省略步骤401,其流程与实施一就基本相似。
另外,实际应用中,步骤401可以在初始化阶段完成,也可以在初始化之后才开始执行。
步骤402~步骤405与实施例一中的步骤301~步骤304相似,此处不再赘述。
步骤406与步骤306相同,此处不再赘述。
应用本实施例方案,客户端和服务器端可以事先协商是否需要进行冲突检测,如果需要,则执行冲突检测以及后继操作;否则,直接按照现有技术进行数据同步。这样,可以为数据冲突检测提供更加灵活的选择。
实施例三
本实施例中,客户端修改条目标识LUID=11的名为“资料”的文件,该文件的大小为2M,其修改的时间为2005年11月26日17点02分;服务器端上该文件的时间戳为2005年11月26日18点30分。本实施例中,服务器端预先配置的仲裁原则为时间戳原则,并规定发生冲突时,按照修改时间在后的条目进行数据同步。
图5显示了本实施例的流程图。如图5所示,本实施例实现检测与解决同步冲突方法包括以下步骤:
步骤501~步骤503与步骤301~步骤303相似,只是本实施例中,当客户端向服务器发送的冲突检测数据包括表示修改时间的时间戳,但不包括条目的修改状态信息。当服务器端从冲突检测数据中提取出条目标识和时间戳之后,可以在利用条目标识查询到对应的条目之后,然后直接根据该条目的条目修改状态信息确定是否发生了冲突。比如:如果自身数据库中的条目进行了修改,不管是什么修改,都可以确认为发生了冲突。
其中,该文件的修改信息可以表示为冲突检测数据格式:
<ConflictDetect>
<CmdID>4</CmdID>
<Cmd>文件的状态为Replace<Cmd>
<Source><LocURI>文件的LUID=11</LocURI></Source>
<Data>指示文件的修改时间(例如:modified&EQ;20051126T170200)<Data>
</ConflictDetect>
步骤504:服务器端按照时间戳仲裁原则对冲突进行仲裁,并确定仲裁结果为按照服务器端的条目进行数据同步。
步骤505和步骤506与实施一的步骤305和步骤306相似,此处不再赘述。
应用本实施例方案,当服务器端接收到包括时间戳信息的冲突检测数据后,提取出其中的条目标识和时间戳信息,根据条目标识查询数据库并确定相应的条目,再直接根据该条目的条目修改状态信息确定是否发生了冲突。比如:如果自身数据库中的条目进行了修改,不管是什么修改,都可以确认为发生了冲突。然后,将冲突检测数据中的时间戳与自身条目的时间戳进行对比,按照时间戳原则确定时间戳为2005年11月26日18点30分的文件修改时间较后,获得仲裁结果,即客户端不需上传数据,而只需由服务器端下发该数据即可;然后,服务器端将自身的文件下发给客户端进行数据同步。
可见,采用本发明所提供的方法,可以减少同步数据的传输量,缩短同步时间,同时降低了网络流量。
实施例四
本实施例中,客户端数据库如表十九所示,服务器端的数据库如表二十所示。
LUID | Name | Status | Fingerprint |
1 | A | Fa | |
2 | B | Fb | |
3 | C | Fc | |
4 | D | Fd | |
5 | E | Fe | |
6 | F | Ff |
表十九
LUID | GUID | Name | Status | Fingerprint |
1 | 1001 | A | Fa | |
2 | 1002 | B | Fb | |
3 | 1003 | C | Fc | |
4 | 1004 | D | Fd | |
5 | 1005 | E | Fe | |
6 | 1006 | F | Ff |
表二十
本实施例中,客户端将LUID=2中的Name字段修改为“Be”,将Fingerprint字段修改为“Fb1”;将LUID=4中的Name字段修改为“De”,将Fingerprint字段修改为“Fd1”;并且删除了LUID=5的条目;增加了LUID=7的条目,其中,Name字段为“H”,Fingerprint字段为“Fh”。同时,服务器端将GUID=1003中的Name字段修改为“Cs”,将Fingerprint字段修改为“Fc1”;将GUID=1004中的Name字段修改为“Ds”,将Fingerprint字段为“Fd1”;删除了GUID=1006的条目;增加了GUID=1008的条目。
图6为本实施例的流程图。如图6所示,本实施例中实现检测和解决冲突的方法包括以下步骤:
步骤601:客户端向服务器端发送智能同步数据请求消息;
这里所述的智能同步的核心思想为:为客户端和服务器各自数据库中的各个数据都设定条目指纹,在同步数据过程中,首先验证条目指纹,即通过对比客户端和服务器各自数据库所存储的数据设定的条目指纹来区分需要同步的数据和垃圾数据,从而在后续数据同步阶段只传输需要同步的数据,避免垃圾数据的传送。
步骤602:服务器端向客户端返回确认消息;
步骤603:客户端将自身数据库中待同步数据条目的条目标识和条目指纹作为冲突检测数据发送给服务器端;
步骤604:服务器端从接收到的冲突检测数据中提取条目标识和条目指纹,并根据提取的条目标识查询自身数据库,确定与提取的条目标识对应的条目;
步骤605:服务器端根据提取的条目指纹和自身相应条目的条目指纹进行对比,检测出冲突。
本实施例中,当服务器端确定提取的条目指纹与自身条目的条目指纹不相同时,就可以判断为发生了冲突。即:只有LUID=1的条目不冲突,LUID=2~LUID=6的条目都发生了冲突,而LUID=7和GUID=1008由于是增加的,判断为不冲突。
步骤606:服务器端根据事先配置的冲突仲裁策略获得冲突仲裁结果。
本实施例中,服务器端可以配置服务器端赢的仲裁策略。实际应用中,还可以配置客户端赢等其它仲裁策略。
步骤607:客户端和服务器端根据冲突仲裁结果进行数据同步。
本实施例中,如果指定客户端和服务器端为双向同步,则服务器端需要将GUID=1002~GUID=1005的条目的数据发送给客户端,并通知客户端删除LUID=6的条目。另外,还需要通知客户端上传LUID=7的条目,并同时把GUID=1008的条目下发给客户端。
实际应用中,如果规定条目指纹由客户端统一计算,则客户端在不同阶段获得GUID=1008条目后,可以先计算出该条目的指纹,并为该条目分配条目标识。之后,再将该条目的条目标识和条目指纹在同步完成阶段返回给服务器端。
而如果规定服务器端可以计算条目指纹,则服务器端可以直接将GUID=1008的条目指纹计算出以后下发给客户端,客户端只需在同步完成阶段向服务器端返回为该条目分配的条目标识即可。
另外,实际应用中,条目指纹可以为条目的摘要值、时间戳、锚值或版本号等。
应用本实施例方案,可以直接根据条目的条目指纹检测冲突,如果发生冲突,再根据冲突仲裁策略获得冲突仲裁结果,确定需要传输哪些数据,不需要传输哪些数据,从而可以节约同步时间、降低了网络流量。
综上所述,以上仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (22)
1、一种检测与解决数据同步冲突的实现方法,其特征在于,所述的实现方法包括以下步骤:
A、客户端与服务器端检测数据同步的冲突,并根据检测的冲突检测数据获得冲突仲裁结果;
B、客户端与服务器端根据获得的冲突仲裁结果进行数据同步。
2、根据权利要求1所述的实现方法,其特征在于,所述步骤A包括:
A1、客户端向服务器端发送冲突检测数据;
A2、服务器端根据接收到的冲突检测数据进行冲突检测,并根据预先配置的冲突仲裁策略获得冲突仲裁结果。
3、根据权利要求2所述的实现方法,其特征在于,所述步骤A2和步骤B之间进一步包括:
A3、服务器端向客户端发送获得的冲突仲裁结果。
4、根据权利要求2或3所述的实现方法,其特征在于,所述冲突检测数据包括客户端条目的条目标识,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AX1、服务器端接收冲突检测数据,并提取出条目标识;
AX2、服务器端根据提取出的条目标识查询自身数据库,确定与所述条目标识对应的服务器端的条目,再根据确定的服务器端条目的修改状态信息检测出冲突。
5、根据权利要求4的实现方法,其特征在于,所述冲突检测数据还包括客户端条目的条目修改状态信息,所述步骤AX1进一步包括:服务器端从冲突检测数据中提取出条目修改状态信息;
步骤AX2所述根据条目的修改状态信息检测出冲突的方法为:
服务器端将提取的条目修改状态信息与自身相应条目的修改状态信息进行对比,检测出冲突。
6、根据权利要求2或3所述的实现方法,其特征在于,所述冲突检测数据包括客户端条目的条目标识和修改字段标识,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AY1、服务器端接收冲突检测数据,提取出条目标识和修改字段标识;
AY2、服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段,然后根据服务器端字段的字段修改状态信息检测出冲突。
7、根据权利要求6所述的实现方法,其特征在于,所述冲突检测数据还包括客户端条目的修改字段状态信息或字段校验和,所述步骤AY1进一步包括:服务器端从冲突检测数据中提取修改字段状态信息或字段校验和;
步骤AY2所述根据服务器端字段的字段修改状态信息检测出冲突的方法为:
服务器端将提取的修改字段状态信息和自身相应字段的修改状态信息进行对比,检测出冲突;或者,
服务器端将提取的字段校验和与自身相应字段的字段校验和进行对比,检测出冲突。
8、根据权利要求2或3所述的实现方法,其特征在于,所述冲突检测数据包括客户端的条目标识和条目指纹,步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为:
AZ1、服务器端接收冲突检测数据,并提取出条目标识和条目指纹;
AZ2、服务器端根据提取出的条目标识在自身数据库中确定与所述条目标识对应的条目,再将提取的条目指纹与自身相应条目的条目指纹进行对比,检测出冲突。
9、根据权利要求8所述的实现方法,其特征在于,所述条目指纹为:
条目的时间戳、摘要值、锚值或版本号。
10、根据权利要求2或3所述的实现方法,其特征在于,所述客户端向服务器端发送冲突检测数据的方法为:客户端通过新增的同步命令或扩充的同步命令将冲突检测数据发送给服务器。
11、根据权利要求3所述的实现方法,其特征在于,所述服务器端向客户端发送冲突仲裁结果的方法为:服务器端通过新增的同步命令或扩充的同步命令将冲突仲裁结果发送给客户端。
12、根据权利要求6所述的实现方法,其特征在于,如果客户端与服务器端修改了同一条目的不同字段,则该方法进一步包括:
所述服务器端在冲突检测时将判定为不冲突,并在数据同步之后将服务器端修改的条目与客户端修改的条目进行合并。
13、根据权利要求2或3所述的实现方法,其特征在于,所述步骤A之前进一步包括:
客户端与服务器端协商是否进行冲突检测。
14、根据权利要求13所述的实现方法,其特征在于,在数据同步协议中增加先解决冲突的同步类型状态码,或增加服务器通知的同步类型状态码,所述客户端与所述服务器端协商的方法为:
X1、所述客户端向所述服务器发送初始化请求;
X2、所述服务器端判断是否同意所述初始化请求中指示的同步类型,如果不同意,则所述客户端与所述服务器端根据配置的同步类型的冲突解决策略,确定同步类型并进入步骤X3;如果同意,则转步骤X3;
X3、所述服务器端判断所述同步类型是否是现有的同步类型,如果是,则按现有的同步流程进行同步,再退出本流程;否则,转步骤A。
15、根据权利要求14所述的实现方法,其特征在于,所述先解决冲突的同步类型状态码为:
先解决冲突且后续为双向同步的同步类型状态码;
或者为先解决冲突且后续为慢同步的同步类型状态码;
或者为先解决冲突且后续同步为客户端的单向同步的同步类型状态码;
或者为先解决冲突且后续同步为客户端的刷新同步的同步类型状态码;
或者为先解决冲突且后续同步为服务器端的单向同步的同步类型状态码;
或者为,增加先解决冲突且后续同步为服务器端的刷新同步的同步类型状态码。
16、根据权利要求14所述的实现方法,其特征在于,所述服务器通知的同步类型状态码为:
服务器端通知,先解决冲突且后续同步为双向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为慢同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为客户端的单向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为客户端的刷新同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为服务器端的单向同步的同步类型状态码;
或者为服务器端通知,先解决冲突且后续同步为服务器端的刷新同步的同步类型状态码;
所述步骤X1之前进一步包括:
服务器端向客户端发送协商通知消息。
17、根据权利要求13所述的实现方法,其特征在于,配置一个先解决冲突的参数,所述客户端与所述服务器端协商的方法为:
Y1、客户端向服务器端发送初始化请求;
Y2、所述服务器端判断所述初始化请求中是否包含所述先解决冲突的参数,若没有,则按现有的同步流程进行同步,再退出本流程;否则转步骤Y3;
Y3、所述服务器端判断是否同意所述初始化请求中的同步类型以及所述先解决冲突的参数,若同意,则转步骤A;否则转步骤Y4;
Y4、同步双方协商,确定进行同步的同步类型以及同步流程,并按照新确定的同步流程进行同步,再退出本流程。
18、根据权利要求13所述的方法,其特征在于,所述客户端与所述服务器端协商的方法为:
客户端向服务器端发送初始化请求,服务器端根据事先配置的协商原则或冲突仲裁原则判断是否进行冲突检测,并向客户端返回协商结果;客户端根据协商结果确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
19、根据权利要求18所述的方法,其特征在于,所述初始化请求包括请求冲突检测的信息。
20、根据权利要求13所述的方法,其特征在于,所述客户端与所述服务器端协商的方法为:
服务器端向客户端发送协商通知命令,客户端根据协商通知命令确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
21、根据权利要求13所述的方法,其特征在于,所述客户端与所述服务器端协商的方法为:
服务器将仲裁原则发送给客户端,客户端直接根据仲裁原则确定是否进行冲突检测,如果是,则执行步骤A;否则,退出本流程。
22、根据权利要求2或3所述的实现方法,其特征在于,所述预先配置的仲裁策略为:
服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006100985899A CN101005428A (zh) | 2006-01-19 | 2006-07-12 | 一种检测与解决数据同步冲突的实现方法 |
EP07702146A EP1953949A4 (en) | 2006-01-19 | 2007-01-19 | Implementation method for data synchronization and associated apparatus |
PCT/CN2007/000215 WO2007082486A1 (fr) | 2006-01-19 | 2007-01-19 | Procédé de synchronisation de données et appareil associé |
US11/959,791 US20080098042A1 (en) | 2006-01-19 | 2007-12-19 | Method for data synchronization and apparatus thereof |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200610033195.5 | 2006-01-19 | ||
CN200610033195 | 2006-01-19 | ||
CNA2006100985899A CN101005428A (zh) | 2006-01-19 | 2006-07-12 | 一种检测与解决数据同步冲突的实现方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101005428A true CN101005428A (zh) | 2007-07-25 |
Family
ID=38287275
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006100985899A Pending CN101005428A (zh) | 2006-01-19 | 2006-07-12 | 一种检测与解决数据同步冲突的实现方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20080098042A1 (zh) |
EP (1) | EP1953949A4 (zh) |
CN (1) | CN101005428A (zh) |
WO (1) | WO2007082486A1 (zh) |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102263663A (zh) * | 2011-08-09 | 2011-11-30 | 北京佳讯飞鸿电气股份有限公司 | 一种网管双机数据维护方法 |
CN102483715A (zh) * | 2009-09-04 | 2012-05-30 | Kii株式会社 | 数据同步系统以及数据同步方法 |
CN102546766A (zh) * | 2010-12-20 | 2012-07-04 | 福特全球技术公司 | 自动维护数据的方法 |
CN102761567A (zh) * | 2011-04-26 | 2012-10-31 | 中国移动通信集团广东有限公司 | 信息同步方法、信息同步引擎及信息同步代理 |
CN103327073A (zh) * | 2008-03-04 | 2013-09-25 | 苹果公司 | 数据同步协议 |
CN103428264A (zh) * | 2013-06-27 | 2013-12-04 | 华为软件技术有限公司 | 数据同步的方法、设备及系统 |
CN103514223A (zh) * | 2012-06-28 | 2014-01-15 | 阿里巴巴集团控股有限公司 | 一种数据仓库数据同步方法和系统 |
CN104468767A (zh) * | 2014-12-01 | 2015-03-25 | 无锡清华信息科学与技术国家实验室物联网技术中心 | 一种云存储数据冲突检测方法及系统 |
CN104639651A (zh) * | 2015-03-04 | 2015-05-20 | 成都维远艾珏信息技术有限公司 | 一种移动设备信息传输方法 |
CN105187475A (zh) * | 2015-06-09 | 2015-12-23 | 深圳市金蝶友商电子商务服务有限公司 | 数据同步的方法和系统 |
CN105404255A (zh) * | 2015-11-03 | 2016-03-16 | 成都天衡电科科技有限公司 | 工业数据网的数据同步方法 |
CN105468650A (zh) * | 2014-09-12 | 2016-04-06 | 阿里巴巴集团控股有限公司 | 一种合并冲突、冲突文件处理方法及装置 |
CN105677655A (zh) * | 2014-11-18 | 2016-06-15 | 阿里巴巴集团控股有限公司 | 一种用于并行开发的架构拆分的分析方法及装置 |
CN108306989A (zh) * | 2018-04-20 | 2018-07-20 | 北京全路通信信号研究设计院集团有限公司 | 一种用于铁路调度集中系统的主备机数据同步方法 |
CN108495336A (zh) * | 2018-02-06 | 2018-09-04 | 珠海市杰理科技股份有限公司 | 基于无线通讯的数据收发方法、装置和计算机设备 |
CN109313634A (zh) * | 2016-03-15 | 2019-02-05 | 微软技术许可有限责任公司 | 用于单个文件的文件同步暂停 |
CN110457395A (zh) * | 2019-08-15 | 2019-11-15 | 中国银行股份有限公司 | 假日数据的同步方法及装置 |
CN110865897A (zh) * | 2018-08-28 | 2020-03-06 | 阿里巴巴集团控股有限公司 | 冲突检测方法和装置以及电子设备 |
CN112800060A (zh) * | 2021-01-28 | 2021-05-14 | 百果园技术(新加坡)有限公司 | 数据处理方法、装置、计算机可读存储介质及电子设备 |
CN113259470A (zh) * | 2021-06-03 | 2021-08-13 | 长视科技股份有限公司 | 一种数据同步的方法及数据同步系统 |
CN114422500A (zh) * | 2021-12-29 | 2022-04-29 | 成都鲁易科技有限公司 | 云备份中文件标识冲突的处理方法、装置及电子设备 |
US20230058148A1 (en) * | 2020-04-13 | 2023-02-23 | Huawei Technologies Co., Ltd. | Detection and resolution of data synchronization conflicts |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101409614B (zh) * | 2007-10-12 | 2011-04-13 | 华为技术有限公司 | 一种数据同步方法、系统和设备 |
JP2009265930A (ja) * | 2008-04-24 | 2009-11-12 | Hitachi Ltd | ストレージサブシステムおよびストレージシステム |
US8078957B2 (en) | 2008-05-02 | 2011-12-13 | Microsoft Corporation | Document synchronization over stateless protocols |
US8010487B2 (en) * | 2008-06-27 | 2011-08-30 | Microsoft Corporation | Synchronization and collaboration within peer-to-peer and client/server environments |
US8019813B2 (en) * | 2009-05-12 | 2011-09-13 | Microsoft Corporation | Synchronizing self-referencing fields during two-way synchronization |
US8219526B2 (en) * | 2009-06-05 | 2012-07-10 | Microsoft Corporation | Synchronizing file partitions utilizing a server storage model |
US8473543B2 (en) | 2009-07-06 | 2013-06-25 | Microsoft Corporation | Automatic conflict resolution when synchronizing data objects between two or more devices |
CN101662760B (zh) * | 2009-07-31 | 2011-12-28 | 中兴通讯股份有限公司 | 将终端数据进行备份的方法及系统 |
KR20110032678A (ko) * | 2009-09-23 | 2011-03-30 | 삼성전자주식회사 | 디스플레이장치, 시스템 및 그 해상도 제어방법 |
ES2820457T3 (es) | 2010-04-12 | 2021-04-21 | Qualcomm Inc | Acuses de recibo retardados para comunicación de baja sobrecarga en una red |
US20110258160A1 (en) * | 2010-04-15 | 2011-10-20 | Po-Yen Lee | Data synchronization methods for synchronizing data in communication system and communication systems |
CA2796448C (en) * | 2010-04-15 | 2019-02-19 | Mxi Technologies Ltd. | Method and system for deployed operations support |
US8918447B2 (en) * | 2010-12-10 | 2014-12-23 | Sap Se | Methods, apparatus, systems and computer readable mediums for use in sharing information between entities |
US8762929B2 (en) * | 2010-12-16 | 2014-06-24 | Sap Ag | System and method for exclusion of inconsistent objects from lifecycle management processes |
US8478719B2 (en) * | 2011-03-17 | 2013-07-02 | Remote Media LLC | System and method for media file synchronization |
US20130013558A1 (en) * | 2011-07-08 | 2013-01-10 | Belk Andrew T | Semantic checks for synchronization: imposing ordinality constraints for relationships via learned ordinality |
US9934229B2 (en) | 2011-10-23 | 2018-04-03 | Microsoft Technology Licensing, Llc | Telemetry file hash and conflict detection |
US10089323B2 (en) | 2012-04-05 | 2018-10-02 | Microsoft Technology Licensing, Llc | Telemetry system for a cloud synchronization system |
US8543540B1 (en) * | 2012-05-09 | 2013-09-24 | Bertec Corporation | System and method for the merging of databases |
US8700569B1 (en) | 2012-05-09 | 2014-04-15 | Bertec Corporation | System and method for the merging of databases |
US9043278B1 (en) | 2012-05-09 | 2015-05-26 | Bertec Corporation | System and method for the merging of databases |
US9934241B2 (en) | 2013-03-05 | 2018-04-03 | Hightail, Inc. | System and method for cloud-based read-only folder synchronization |
JP2015028684A (ja) * | 2013-07-30 | 2015-02-12 | 株式会社日立製作所 | 営業支援方法および営業支援システム |
US10402744B2 (en) | 2013-11-18 | 2019-09-03 | International Busniess Machines Corporation | Automatically self-learning bidirectional synchronization of a source system and a target system |
US9542467B2 (en) * | 2013-11-18 | 2017-01-10 | International Business Machines Corporation | Efficiently firing mapping and transform rules during bidirectional synchronization |
CN103906117B (zh) * | 2014-03-31 | 2017-08-01 | 大唐移动通信设备有限公司 | 一种x2链路冲突解决方法及装置 |
US10825056B1 (en) * | 2014-04-17 | 2020-11-03 | The Nielsen Company (Us), Llc | Client-side video advertisement replacement using automatic content recognition |
CN108885622A (zh) * | 2016-04-06 | 2018-11-23 | 华为技术有限公司 | 多主同步复制优化的系统和方法 |
CN110674156B (zh) * | 2019-09-27 | 2020-06-26 | 掌阅科技股份有限公司 | 多机房数据的同步方法、计算设备及计算机存储介质 |
US11763427B2 (en) * | 2020-03-31 | 2023-09-19 | Unity IPR ApS | Method and system for intelligent importing and transformation of digital assets |
CN115765905A (zh) * | 2022-09-16 | 2023-03-07 | 南京红薯网络科技有限公司 | 一种基于云游戏平台的网络帧同步检测系统及检测平台 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5684990A (en) * | 1995-01-11 | 1997-11-04 | Puma Technology, Inc. | Synchronization of disparate databases |
US5790848A (en) * | 1995-02-03 | 1998-08-04 | Dex Information Systems, Inc. | Method and apparatus for data access and update in a shared file environment |
US6269369B1 (en) * | 1997-11-02 | 2001-07-31 | Amazon.Com Holdings, Inc. | Networked personal contact manager |
US6944642B1 (en) * | 1999-10-04 | 2005-09-13 | Microsoft Corporation | Systems and methods for detecting and resolving resource conflicts |
US6671757B1 (en) * | 2000-01-26 | 2003-12-30 | Fusionone, Inc. | Data transfer and synchronization system |
US7536421B2 (en) * | 2003-10-31 | 2009-05-19 | Landmark Technology Partners, Inc. | Intelligent client architecture computer system and method |
US7543042B2 (en) * | 2004-04-28 | 2009-06-02 | International Business Machines Corporation | Remote access method for accessing dynacache data |
-
2006
- 2006-07-12 CN CNA2006100985899A patent/CN101005428A/zh active Pending
-
2007
- 2007-01-19 WO PCT/CN2007/000215 patent/WO2007082486A1/zh active Application Filing
- 2007-01-19 EP EP07702146A patent/EP1953949A4/en not_active Withdrawn
- 2007-12-19 US US11/959,791 patent/US20080098042A1/en not_active Abandoned
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103327073B (zh) * | 2008-03-04 | 2016-09-07 | 苹果公司 | 数据同步协议 |
CN103327073A (zh) * | 2008-03-04 | 2013-09-25 | 苹果公司 | 数据同步协议 |
CN102483715A (zh) * | 2009-09-04 | 2012-05-30 | Kii株式会社 | 数据同步系统以及数据同步方法 |
CN102546766A (zh) * | 2010-12-20 | 2012-07-04 | 福特全球技术公司 | 自动维护数据的方法 |
CN102546766B (zh) * | 2010-12-20 | 2017-04-12 | 福特全球技术公司 | 自动维护数据的方法 |
CN102761567A (zh) * | 2011-04-26 | 2012-10-31 | 中国移动通信集团广东有限公司 | 信息同步方法、信息同步引擎及信息同步代理 |
CN102263663A (zh) * | 2011-08-09 | 2011-11-30 | 北京佳讯飞鸿电气股份有限公司 | 一种网管双机数据维护方法 |
CN103514223B (zh) * | 2012-06-28 | 2017-09-01 | 阿里巴巴集团控股有限公司 | 一种数据仓库数据同步方法和系统 |
CN103514223A (zh) * | 2012-06-28 | 2014-01-15 | 阿里巴巴集团控股有限公司 | 一种数据仓库数据同步方法和系统 |
CN103428264B (zh) * | 2013-06-27 | 2016-12-28 | 华为软件技术有限公司 | 数据同步的方法、设备及系统 |
CN103428264A (zh) * | 2013-06-27 | 2013-12-04 | 华为软件技术有限公司 | 数据同步的方法、设备及系统 |
CN105468650A (zh) * | 2014-09-12 | 2016-04-06 | 阿里巴巴集团控股有限公司 | 一种合并冲突、冲突文件处理方法及装置 |
CN105677655B (zh) * | 2014-11-18 | 2019-01-22 | 阿里巴巴集团控股有限公司 | 一种用于并行开发的架构拆分的分析方法及装置 |
CN105677655A (zh) * | 2014-11-18 | 2016-06-15 | 阿里巴巴集团控股有限公司 | 一种用于并行开发的架构拆分的分析方法及装置 |
CN104468767A (zh) * | 2014-12-01 | 2015-03-25 | 无锡清华信息科学与技术国家实验室物联网技术中心 | 一种云存储数据冲突检测方法及系统 |
CN104468767B (zh) * | 2014-12-01 | 2017-12-12 | 无锡清华信息科学与技术国家实验室物联网技术中心 | 一种云存储数据冲突检测方法及系统 |
CN104639651A (zh) * | 2015-03-04 | 2015-05-20 | 成都维远艾珏信息技术有限公司 | 一种移动设备信息传输方法 |
CN105187475B (zh) * | 2015-06-09 | 2018-10-12 | 深圳金蝶账无忧网络科技有限公司 | 数据同步的方法和系统 |
CN105187475A (zh) * | 2015-06-09 | 2015-12-23 | 深圳市金蝶友商电子商务服务有限公司 | 数据同步的方法和系统 |
CN105404255B (zh) * | 2015-11-03 | 2017-12-26 | 成都天衡电科科技有限公司 | 工业数据网的数据同步方法 |
CN105404255A (zh) * | 2015-11-03 | 2016-03-16 | 成都天衡电科科技有限公司 | 工业数据网的数据同步方法 |
CN109313634B (zh) * | 2016-03-15 | 2021-12-21 | 微软技术许可有限责任公司 | 用于单个文件的文件同步暂停 |
CN109313634A (zh) * | 2016-03-15 | 2019-02-05 | 微软技术许可有限责任公司 | 用于单个文件的文件同步暂停 |
CN108495336A (zh) * | 2018-02-06 | 2018-09-04 | 珠海市杰理科技股份有限公司 | 基于无线通讯的数据收发方法、装置和计算机设备 |
CN108495336B (zh) * | 2018-02-06 | 2021-09-17 | 珠海市杰理科技股份有限公司 | 基于无线通讯的数据收发方法、装置和计算机设备 |
CN108306989A (zh) * | 2018-04-20 | 2018-07-20 | 北京全路通信信号研究设计院集团有限公司 | 一种用于铁路调度集中系统的主备机数据同步方法 |
CN110865897A (zh) * | 2018-08-28 | 2020-03-06 | 阿里巴巴集团控股有限公司 | 冲突检测方法和装置以及电子设备 |
CN110865897B (zh) * | 2018-08-28 | 2023-05-02 | 阿里巴巴集团控股有限公司 | 冲突检测方法和装置以及电子设备 |
CN110457395A (zh) * | 2019-08-15 | 2019-11-15 | 中国银行股份有限公司 | 假日数据的同步方法及装置 |
US20230058148A1 (en) * | 2020-04-13 | 2023-02-23 | Huawei Technologies Co., Ltd. | Detection and resolution of data synchronization conflicts |
CN112800060A (zh) * | 2021-01-28 | 2021-05-14 | 百果园技术(新加坡)有限公司 | 数据处理方法、装置、计算机可读存储介质及电子设备 |
CN113259470A (zh) * | 2021-06-03 | 2021-08-13 | 长视科技股份有限公司 | 一种数据同步的方法及数据同步系统 |
CN114422500A (zh) * | 2021-12-29 | 2022-04-29 | 成都鲁易科技有限公司 | 云备份中文件标识冲突的处理方法、装置及电子设备 |
CN114422500B (zh) * | 2021-12-29 | 2023-05-09 | 成都鲁易科技有限公司 | 云备份中文件标识冲突的处理方法、装置及电子设备 |
Also Published As
Publication number | Publication date |
---|---|
EP1953949A1 (en) | 2008-08-06 |
WO2007082486A1 (fr) | 2007-07-26 |
US20080098042A1 (en) | 2008-04-24 |
EP1953949A4 (en) | 2009-04-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101005428A (zh) | 一种检测与解决数据同步冲突的实现方法 | |
CN101160903B (zh) | 一种实现数据同步的方法、系统、客户端及服务器 | |
CN1956452B (zh) | 一种实现数据同步的方法、系统、客户端及服务器 | |
US6763346B1 (en) | Document service integrated system | |
US9594821B2 (en) | Method and apparatus for synchronizing how data is stored in different data stores | |
CN103516591B (zh) | 即时通信平台中企业通讯录的实现方法和装置 | |
CN101876983B (zh) | 数据库分区方法与系统 | |
CN1656480B (zh) | 允许同步具备不同能力的不同设备中的数据的方法和设备 | |
CN101146106B (zh) | 级联发现web服务 | |
CN101568919B (zh) | 具有分布式存储的联网计算机系统中的单个数据视图 | |
CN102088519A (zh) | 通讯录管理方法及其装置 | |
EP2317785B1 (en) | Address list system and implementation method thereof | |
CN102098211B (zh) | 客户端和服务器动态协助的业务聚合方法、服务器和客户端 | |
CN101065947A (zh) | Web服务注册和操作方法 | |
CN101500208A (zh) | 设备间数据同步的方法和系统 | |
CN101421726A (zh) | 偶尔连接的应用服务器 | |
CN100458790C (zh) | 访问数据库的方法和系统 | |
JP6652237B2 (ja) | 法人番号検索装置、システム、方法、プログラム及び法人番号追加プログラム | |
CN107870982B (zh) | 数据处理方法、系统和计算机可读存储介质 | |
CN102760164B (zh) | 一种关系数据库管理系统与xml数据库管理系统之间数据交换的方法 | |
CN106933555A (zh) | 一种数据框架系统 | |
US8694559B2 (en) | Using database content for multiple business data systems connected to one database | |
CN102103611A (zh) | 一种信息存储、或读取的方法及装置 | |
US20090243812A1 (en) | Information service system | |
CN101384050A (zh) | 一种移动终端及其资源管理的方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |