此客户端服务器设计是否有意义？这是否实用？

Question

我一直在努力的应用程序的基本思想是允许用户组在闪存卡的“堆栈”上进行协作。最终，应用程序将作为客户端 - 服务器系统（与iOS应用作为客户端，和一个Rails应用程序的服务器）

这种设计的要求，因为我看到他们，就像这样：

1. 它需要处理合并编辑顺利。由于许多用户将编辑每个堆栈，并且因为每个客户端可能无法在完成后立即上载其更改，因此设计需要能够优雅地协调对共享数据的不一致更改。
2. 它需要高效。由于许多用户将通过他们的单元连接访问应用程序，因此我需要最大限度地减少从服务器上载和下载的数据量，以确保应用程序能够在这些连接上快速运行，并减少已受限客户端的数据使用量。

本来我只是走简单的路线，让客户端在每次同步时向服务器发送一个“批量”报告，这意味着每个堆栈的整个本地副本将被上传，然后服务器会处理所有这些事情，然后将整个新数据集发送到客户端，然后将这些准确副本保存为离线查看和编辑，然后将其合并到以前客户端编辑的主副本中。

我看到这个问题，牢记我的设计要求，主要是它的效率非常低。客户端应用程序不仅不得不浪费时间上传和下载所有这些数据，还必须将所有新信息写入其本地数据存储区，尽管其中大部分信息与以前的副本相同。我也无法理解服务器如何以有效且合乎逻辑的方式理解冲突编辑的意义。

所以这里就是我想出了：

每当客户端进行了更改共享堆栈，除了改变自己的数据库的副本，它会记下变化的包括什么被改变，如何，何时，以及由谁改变。当客户端下次与服务器同步时，无论在第二天还是几天内，都会将此“收到”操作发送到服务器，而不是整个本地数据副本。

在那里，服务器首先存储这些行为的后代，然后执行数据的服务器副本上的所有更改。然后，它使用这个收据数据库来抓取自上次客户端与数据库同步以来对Stack的所有相关更改。只有这些信息才会发送回客户端，客户端会在其本地副本上运行更改。

使用此日志记录了客户端所做的所有更改，服务器可以决定哪些更改使其他更改无效（例如，如果用户删除了一张卡，然后在与此更改同步之前，另一用户编辑了正常的卡，那么删除将失效）。虽然执行起来很复杂，但理论上这对我的合并问题来说是一个理想的解决方案。

那么你怎么看？

这是一个可行的解决方案？你在我的总体规划中是否看到任何明显的漏洞？

谢谢！

Answer 1

有一点需要注意的是不能从设备信任时间作为算法的一部分：

Can I Rely on the iOS Device Clock Being Correct?

我关于这一点，并合并/交织处理线程会谈答案。

您可能需要考虑两个用户是否在同一张卡上编辑同一个有冲突的数据。由于您不能相信时间，因此客户端确实知道上次同步的最后一个“服务器时间标记”，因此您可以将所有更改记录在最后一个同步服务器标记中。所做的就是奖励客户端进行同步，因为客户端可以确信（服务器的时间）唯一可以交换的变化。

希望有所帮助。绝对是一个复杂的话题，要做到正确（和一般）。