使用增量改进客户端 - 服务器数据同步功能

Question

该应用
我有一个当前使用AppCache的网络应用程序用于离线功能，因为系统用户需要离线创建文档。该文档首先是离线创建的，当互联网访问可用时，用户可以单击“同步”，将文档发送到服务器并将其另存为修订版。更具体地说，应用程序不会将更改增量保存为修订版（修改的确切字段），而是保存整个文档的全部内容。换句话说，保存了“快照”文档。

问题
用户可以从不同的浏览器和设备登录并处理他们的文档。当他们点击“同步”时，如果服务器的文档较新，整个客户端的版本将被服务器覆盖。这导致了一个主要问题，如下图所示。

上面的场景是因为当前的实现不依赖于增量（小的更改）而是依赖于快照修订。

一些问题

1）我的研究表明，我应该升级“同步”机制，以增量表达（可以独立应用的小变化）。这是一个合理的方法吗？

2）每个delta应该独立应用吗？

2）根据我的研究，修订增量有一个数值而不是时间戳。它的价值应该是什么？我如何确保服务器和客户端都同意修订号应该是什么？

堆叠信息

• 前端的角度
• IndexedDB在本地保存文档（离线模式）
• 后端使用JSONB的Postgres DB

Answer 1

您所描述的是this question中的版本控制问题。您可以选择如何解决问题。以下是此问题的其他产品的几个示例：

• Google文档：A离线编辑，B在线编辑，A上线，同步，Google文档结合A和B的编辑
• Apple注意：与Google Docs相同
• Git / Subversion：抛出错误，要求用户解决冲突
• 奇妙清单：上次修改会覆盖之前的

对于您的情况，这个最简单的解决方案是使用Wunderlist的方法，但似乎可能会导致可用性问题。您的用户期望发生什么？

直接回答您的问题：

1. 如果您不想覆盖，则需要自定义同步实施。
2. 这是一个可用性决定，用户期望什么？
3. 是的，修订是数字的（例如r1，r2）。要获得服务器协议，请更改上次同步请求的返回值。您可以每次将整个模型返回给客户端（如果发生正常同步，则只返回200 OK）。如果将模型返回给客户端，请使用最新模型更新客户端。

无论如何，服务器应始终是真相的来源。 This post提供了有关服务器/移动参照完整性的一些好建议：

  

要跟踪插入，您需要创建时间戳...要跟踪您需要跟踪行上LastUpdate时间戳的更新...要跟踪删除，您需要一个逻辑删除表。

     

请注意，执行同步时，需要检查服务器和移动设备之间的时间偏移，并且需要一种解决冲突的方法。插入没什么大不了的（它们不应该发生冲突），但更新可能会发生冲突，删除可能会与更新发生冲突。