Ie：假设记录＃125在服务器上被更改了，那么你必须决定的事情是关于哪一侧在更改冲突的情况下被认为是 1月5日晚上10点，同一条记录在1月5日晚上11点更改了其中一部手机（我们称之为客户A）。
最后一次同步是在1月3日。然后用户重新连接，例如1月8日。

I.e.: suppose Record #125 is changed on the server on January 5th at 10pm and the same record is changed on one of the phones (let's call it Client A) on January 5th at 11pm. Last synch was on Jan 3rd. Then the user reconnects on, say, January 8th.

识别需要更改的是简单，客户端和服务器都知道日期

Identifying what needs to be changed is "easy" in the sense that both the client and the server know the date of the last synch, so anything created or updated (see below for more on this) since the last synch needs to be reconciled.

因此，最后一次同步是最后一次同步，所以任何创建或更新假设唯一改变的记录是＃125。
您可以决定两者之一自动胜利并覆盖另一个，或者您需要支持一个协调阶段，用户可以决定哪个版本（服务器或客户端）是正确的，覆盖另一个版本。

So, suppose that the only changed record is #125. You either decide that one of the two automatically "wins" and overwrites the other, or you need to support a reconcile phase where a user can decide which version (server or client) is the correct one, overwriting the other.

这个决定是非常重要的，你必须重视客户的角色。特别是如果不仅在客户端和服务器之间存在潜在冲突，而且在不同的客户端可以更改相同的记录的情况下。

This decision is extremely important and you must weight the "role" of the clients. Especially if there is a potential conflict not only between client and server, but in case different clients can change the same record(s).

[假设＃125可以由第二客户端（客户端B）修改，有可能尚未同步的客户端B将提供同一记录的另一版本，使得先前的冲突解决方案

[Assuming that #125 can be modified by a second client (Client B) there is a chance that Client B, which hasn't synched yet, will provide yet another version of the same record, making the previous conflict resolution moot]

关于创建或更新上面的...如何在一个客户端上创建记录（假设这在您的问题中是有意义的）域）？
假设您的应用程序管理业务联系人列表。如果客户A说你必须添加一个新创建的约翰·史密斯，并且服务器有一个约翰史密斯昨天由客户端D创建...你创建两个记录，因为你不能确定他们不是不同的人？

Regarding the "created or updated" point above... how can you properly identify a record if it has been originated on one of the clients (assuming this makes sense in your problem domain)? Let's suppose your app manages a list of business contacts. If Client A says you have to add a newly created John Smith, and the server has a John Smith created yesterday by Client D... do you create two records because you cannot be certain that they aren't different persons? Will you ask the user to reconcile this conflict too?

客户端是否拥有数据子集的所有权？也就是说如果客户端B被设置为区域＃5的数据的权威，客户端A是否可以修改/创建区域＃5的记录？

Do clients have "ownership" of a subset of data? I.e. if Client B is setup to be the "authority" on data for Area #5 can Client A modify/create records for Area #5 or not? (This would make some conflict resolution easier, but may prove unfeasible for your situation).

总而言之，主要的问题是：

To sum it up the main problems are:

• 考虑到分离的客户端在创建新记录之前可能没有访问过服务器，如何定义身份。


• ，无论解决方案多么复杂，都可能导致数据重复，因此您必须预见如何定期解决这些问题，以及如何通知客户端他们认为记录＃675实际上已被合并/取代为记录＃543


• 决定是否可以通过 fiat 解决冲突（例如如果前一个版本自上次同步以来服务器版本始终胜过客户端）或手动干预


• 在 fiat 的情况下，特别是如果您决定客户端优先，您还必须照顾如何处理其他，


• 以前的项目不会考虑您的数据的粒度（以便更简单地描述）。只要说，而不是在记录级别推理，如在我的例子，你可能会发现更适合在字段级记录更改，而不是。或者一次处理一组记录（例如，人员记录+地址记录+联系人记录），将其聚合作为一种元记录处理。

• How to define "identity" considering that detached clients may not have accessed the server before creating a new record.
• The previous situation, no matter how sophisticated the solution, may result in data duplication, so you must foresee how to periodically solve these and how to inform the clients that what they considered as "Record #675" has actually been merged with/superseded by Record #543
• Decide if conflicts will be resolved by fiat (e.g. "The server version always trumps the client's if the former has been updated since the last synch") or by manual intervention
• In case of fiat, especially if you decide that the client takes precedence, you must also take care of how to deal with other, not-yet-synched clients that may have some more changes coming.
• The previous items don't take in account the granularity of your data (in order to make things simpler to describe). Suffice to say that instead of reasoning at the "Record" level, as in my example, you may find more appropriate to record change at the field level, instead. Or to work on a set of records (e.g. Person record + Address record + Contacts record) at a time treating their aggregate as a sort of "Meta Record".

参考书目：

• 更多关于这一点，当然， Wikipedia 。

一个简单的同步算法作者 Vdirsyncer

OBJC数据同步文章

SyncML®：同步和管理您的移动数据（O'Reilly Safari上的书）

SyncML®: Synchronizing and Managing Your Mobile Data (Book on O'Reilly Safari)

抵触复制的数据类型

乐观复制 YASUSHI SAITO（HP实验室）和MARC SHAPIRO（微软研究有限公司） - ACM Computing Surveys， V，No.N，3 2005。

Optimistic Replication YASUSHI SAITO (HP Laboratories) and MARC SHAPIRO (Microsoft Research Ltd.) - ACM Computing Surveys, Vol. V, No. N, 3 2005.

Alexander Traud，Juergen Nagler-Ihlein，Frank Kargl和Michael Weber。通过重用SyncML的循环数据同步。在第九届国际移动数据管理会议（MDM '08）。 IEEE Computer Society，Washington，DC，USA，165-172。 DOI = 10.1109 / MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10

Alexander Traud, Juergen Nagler-Ihlein, Frank Kargl, and Michael Weber. 2008. Cyclic Data Synchronization through Reusing SyncML. In Proceedings of the The Ninth International Conference on Mobile Data Management (MDM '08). IEEE Computer Society, Washington, DC, USA, 165-172. DOI=10.1109/MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10

Lam，F.，Lam，N.和Wong，R.2002.Efficient synchronization for mobile XML data。在第十一届国际信息与知识管理大会会议记录（麦克莱恩，美国弗吉尼亚，2002年11月4日 - 09日）。 CIKM'02。 ACM，New York，NY，153-160。 DOI = http://doi.acm.org/10.1145/584792.584820

Lam, F., Lam, N., and Wong, R. 2002. Efficient synchronization for mobile XML data. In Proceedings of the Eleventh international Conference on information and Knowledge Management (McLean, Virginia, USA, November 04 - 09, 2002). CIKM '02. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/584792.584820

Cunha，PR和Maibaum，TS 1981. Resource&equil;抽象数据类型+同步 - 面向消息的编程的一种方法。在Proceedings of the 5th international Conference on Software Engineering（San Diego，California，United States，March 09 - 12，1981）中。国际软件工程会议。 IEEE Press，Piscataway，NJ，263-272。

Cunha, P. R. and Maibaum, T. S. 1981. Resource &equil; abstract data type + synchronization - A methodology for message oriented programming -. In Proceedings of the 5th international Conference on Software Engineering (San Diego, California, United States, March 09 - 12, 1981). International Conference on Software Engineering. IEEE Press, Piscataway, NJ, 263-272.

从 Dr.Dobbs 网站：

• 使用SQL Server CE和SQL RDA创建应用程序Bill Wagner May 19，2004（设计桌面和移动PC应用程序的***做法 - Windows / .NET）

从arxiv.org ：

From arxiv.org:

• 冲突 - 免费复制JSON数据类型 - 本文介绍了一个JSON CRDT实现（无冲突复制数据类型 - CRDT - 是一组支持并发修改并保证此类并发更新收敛的数据结构）。

• A Conflict-Free Replicated JSON Datatype - the paper describes a JSON CRDT implementation (Conflict-free replicated datatypes - CRDTs - are a family of data structures that support concurrent modification and that guarantee convergence of such concurrent updates).