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

Question

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

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

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

一些问题

1)我的研究表明,我应该将"同步"机制升级为以增量表示(可以独立应用的小变化).这是一个合理的方法吗？

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

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

堆栈信息

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

Answer 1

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

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

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

直接回答您的问题:

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

无论如何,服务器应始终是真相的来源.这篇文章提供了一些关于服务器/移动参照完整性的好建议:

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

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