ruby-on-rails - 这种客户端-服务器设计有意义吗？实用吗？

Question

我一直在开发的应用程序的基本思想是允许用户组在闪存卡“堆栈”上进行协作。最终，该应用程序将充当客户端-服务器系统(iOS 应用程序作为客户端，Rails 应用程序作为服务器)

这个设计的要求，在我看来是这样的:

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

最初我只是打算采用简单的路线，让客户端在每次同步时向服务器发送“批量”报告，这意味着每个堆栈的整个本地副本将被上传，然后服务器将处理所有这一切，将其与以前客户的编辑合并到自己的主副本中，然后将整个新数据集发送给客户，客户将保存此准确的副本以供离线查看和编辑。

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

这就是我的想法:

每当客户端对共享堆栈进行更改时，除了更改自己的数据库副本之外，它还会在日志中记录更改，包括更改内容、更改方式、更改时间以及更改者。下次客户端与服务器同步时，无论是在一秒钟还是几天内，此操作“收据”都会发送到服务器，而不是整个本地数据副本。

在那里，服务器首先存储这些操作以供后代使用，然后再对数据的服务器副本执行所有更改。然后，它使用此收据数据库来获取自上次客户端与数据库同步以来对堆栈的所有相关更改。然后只有这些被发送回客户端，客户端在其自己的本地副本上运行更改。

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

那你觉得怎么样？

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

谢谢!

Answer 1

需要注意的一件事是不要相信设备的时间作为算法的一部分:

Can I Rely on the iOS Device Clock Being Correct?

我对该主题的回答谈到了这一点以及合并/交错操作。

您可能需要考虑两个用户是否在同一张卡上编辑相同的冲突数据。由于您不能信任时间，因此客户端确实知道最后一次同步的最后一个“服务器时间标记”，因此您可以将所有更改归功于最后一次同步服务器标记。这样做的作用是奖励更频繁同步的客户端，因为它通过您唯一可以确定的事情(服务器的时间)交错更改。

希望有帮助。绝对是一个需要正确(且一般地)完成的复杂主题。