客户端 – 服务器同步模式/algorithm？

我有一种感觉，那里必须有客户端 – 服务器同步模式。但我完全没有谷歌上一个。

情况很简单 – 服务器是中心节点，多个客户端连接并操纵相同的数据。数据可以拆分成primefaces，万一发生冲突，服务器上的任何东西都有优先权（避免让用户冲突解决）。由于潜在的大量数据，部分同步是首选。

有没有这种情况的模式/好的做法，或者如果你不知道 – 你会采取什么做法？

以下是我现在想要解决的问题：与数据并行，修改日志将被执行，所有交易都有时间戳。当客户端连接时，它会以统一的forms接收自上次检查以来发生的所有更改（服务器会通过列表并删除随后删除的添加，合并每个primefaces的更新等）。 Et瞧，我们是最新的。

替代scheme是保持每个logging的修改date，而不是执行数据删除，只需将它们标记为已删除。

有什么想法吗？

您应该看看分布式更改pipe理如何工作。看看SVN，CVS和其他pipe理增量工作的仓库。

你有几个用例。

同步更改。您的更改日志（或增量历史logging）方法看起来不错。客户端发送他们的deltas到服务器; 服务器整合并向客户端分发增量。这是典型的情况。数据库称之为“事务复制”。
客户端已失去同步。无论是通过备份/恢复还是由于错误。在这种情况下，客户端需要从服务器获取当前状态，而不需要通过增量。这是从大师到细节的副本，三angular洲和性能是该死的。这是一次性的事情; 客户坏了; 不要试图优化这个，只是实现一个可靠的副本。
客户是可疑的。在这种情况下，您需要比较客户端和服务器，以确定客户端是否是最新的并需要任何增量。

你应该按照数据库（和SVN）devise模式按顺序编号每一个变化。这样，客户端可以在尝试同步之前发出微不足道的请求（“我应该做什么修改？”）。即使如此，查询（“自2149年以来的所有增量”）对于客户端和服务器来说是非常简单的处理。

你真正需要的是运营转型（OT）。这在很多情况下甚至可以迎合冲突。

这仍然是一个活跃的研究领域，但是有各种OTalgorithm的实现。我已经参与了这么多年的研究，所以让我知道这条路线是否令您感兴趣，我很乐意将您介绍给相关的资源。

作为团队的一部分，我做了很多涉及数据同步的项目，所以我应该有能力回答这个问题。

数据同步是一个相当广泛的概念，有太多可以讨论的地方。它涵盖了一系列不同的方法，有其优缺点。这是基于两个angular度的可能的分类之一：同步/asynchronous，客户端/服务器/对等。同步实施严重依赖于这些因素，数据模型的复杂性，传输和存储的数据量以及其他要求。所以在每个特定的情况下，select应该是满足应用程序要求的最简单的实现。

基于对现有现成解决scheme的回顾，我们可以描述几个主要的同步类，不同粒度的对象需要同步：

整个文档或数据库的同步用于基于云的应用程序，如Dropbox，Google Drive或Yandex.Disk。当用户编辑并保存文件时，新的文件版本将完全上传到云端，覆盖较早的副本。如果发生冲突，则保存两个文件版本，以便用户可以select哪个版本更相关。
键值对的同步可以在具有简单数据结构的应用程序中使用，其中variables被认为是primefaces的，即不被分成逻辑组件。该选项类似于整个文档的同步，因为值和文档都可以被完全覆盖。然而，从用户的angular度来看，文档是由许多部分组成的复杂对象，但是键值对只是一个短的string或数字。因此，在这种情况下，我们可以使用一个更简单的解决冲突的策略，考虑到价值更为相关，如果它是最后的变化。
将结构化为树或图的数据同步用于更复杂的应用程序，其中数据量足够大以在每次更新时完整地发送数据库。在这种情况下，冲突必须在个体对象，领域或关系的层面上解决。我们主要关注这个选项。

因此，我们将这些知识应用到了这篇文章中，我认为这对于所有对“基于核心数据的iOS应用程序中的数据同步”感兴趣的人都是非常有用的（ http://blog.denivip.ru/index.php/2014/04 / data-in-core-data-based-ios-apps /？lang = en ）

这个问题不是很清楚，但是如果我是你，我会考虑乐观的locking 。它可以用服务器为每个logging返回的序列号来实现。当客户端尝试保存logging时，它将包含从服务器收到的序列号。如果序列号与接收到更新时的数据库中的内容相匹配，则允许更新，序列号递增。如果序列号不匹配，则不允许更新。

对于增量（更改）同步，您可以使用pubsub模式将更改发回给所有订阅的客户端，像pusher这样的服务可以执行此操作。

对于数据库镜像，一些Web框架使用本地微型数据库将服务器端数据库同步到浏览器数据库的本地，支持部分同步。检查meteror 。