这个问题有点笼统，所以为了缩小关注范围，我将分享我目前正在激发这个问题的设置。我有一个运行RESTful API的LAMP Web服务。我们有两个客户端实现：一个基于浏览器的javascript客户端（本地存储库）和一个基于iOS的客户端（核心数据存储）。显然，这两个客户端存储的数据差异很大，但数据本身需要尽可能多地与远程服务器保持同步。
目前，我们的“同步”过程有点愚蠢（如非智能）。从概念上讲，它看起来像：
数据本身以关系方式存储，并由客户端用户偶尔更新。在我的具体情况下，客户对关系本身并不太在意（这就是我们现在可以在浏览器客户端中使用本地存储的原因）。
显然这不是真正的同步。我想转移到一个系统，在概念上，最近的更改的“差异”定期发送到服务器，服务器发回它所知道的最新更改的“差异”。达到这一点似乎很难，但也许我只是不太了解这个问题。
REST感觉是一个好的开始，但REST只讨论了两个数据存储相互通信的方式，而不是数据本身如何在它们之间进行同步。 （此同步过程由每个商店的实施者决定。）实施此过程的最佳方法是什么？是否有一组现代的编程设计模式适用于通知特定的解决方案？如果可能的话，我最感兴趣的是一般的（技术不可知）方法......但是如果它们存在的话，特定的框架也会很有用。
答案 0 :(得分：4)
多主复制总是（并且将永远是）困难和定制的，因为处理冲突的方式将特定于您的应用程序。
IMO更强大的方法是使用主从复制，将您的Web服务作为主服务器，将客户端作为从服务器。为了使客户端保持同步，请使用更改的归档原子提要（请参阅event sourcing)按RFC5005。这是您最接近此类复制的现代标准，它是RESTful
当客户端在线时，他们不会直接更新他们的副本，而是将命令发送到服务器并通过原子源更新他们的副本。
当客户离线时，事情变得困难。您的客户需要具有Web服务行为的模型。它需要具有副本的脱机副本，该副本应该是来自联机副本的copied on write（联机副本是由原子源更新的副本）。当客户端执行修改数据的命令时，它应该存储命令（以便以后重放Web服务），预期结果（用于重放期间的验证）并更新脱机副本。
当客户端重新联机时，它应重播命令，将结果与预期结果进行比较，并通知客户端任何差异。如何处理这些差异将根据您的应用程序而有所不同。然后可以丢弃脱机副本。
答案 1 :(得分：1)
CouchDB复制通过HTTP工作，并完成您要执行的操作。一旦数据库在任何一端同步，它将发送添加/更新/删除的差异。
Couch可以与其他Couch机器或TouchDB等移动框架一起使用。
https://github.com/couchbaselabs/TouchDB-iOS
我已经完成了相当多的工作，但你总是可以在一台机器上设置CouchDB，在移动设备上设置TouchDB，然后观察HTTP流量的来回，以了解他们是如何做到的
或者阅读：http://guide.couchdb.org/draft/replication.html
上面的链接中的某些内容可能会帮助您了解如何为REST服务执行自己的差异。 （因为它们都是通过HTTP认为它可能有用。）
答案 2 :(得分：0)
您可能需要查看Dropbox数据存储区API：
https://www.dropbox.com/developers/datastore
听起来它可能非常适合您的目的。他们有iOS和javascript客户端。
答案 3 :(得分：0)