- 主题:请教前端与后端的数据的同步的设计模式
前端只做缓存。所有数据必在后端有对应的备份。
剩下的就是缓存管理这件人人都会的简单事了。
【 在 misslost (一千零一夜梦中人) 的大作中提到: 】
: 现在的前端都是大前端，后端只是通过接口传送数据，前端也可以使用本地数据库（app或者web）来保存数据或者缓存数据。这就涉及到客户端和服务端的数据同步问题。这方面，前后端的数据同步和缓存，有没有比较成熟的算法或者设计模式，或者开源的参考的应用？
: 谢谢
--
FROM 47.243.39.*
看了一下你的新想法，本质上还是数据缓存的管理。所以你找找缓存相关的教科书看看应该就差不多了。所谓 write-through, write-back.
建议你的数据结构设计成不会冲突的，无论客户端提交多少次，都不会产生重复的数据。剩下的事情都好办。
【 在 misslost 的大作中提到: 】
: 我更新了一下我的想法。麻烦再帮我看看。
--
FROM 47.243.39.*
这个参考 git 吧。
我前年也做了一个类似的，解决办法是没同步到最新的数据就返回修改失败。模型很简单，但偶尔会让用户修改失败，得重新打开修改。
【 在 misslost 的大作中提到: 】
: 这种模式其实很复杂的。
: 数据之间是否冲突，不是跟开发人员能决定的，很多结构是业务本身的需求决定的。尤其是涉及多用户之间交互的互联网系统，这种冲突是必须面对和解决的。
: 打个比方。假设业务是这样的：A在论坛上发帖pa，B查看该贴pa，业务上AB都有修改pa的权限，然后A和B都同时打开pa进行编辑。此时，必然会面临数据的冲突。
: ...................
--
FROM 47.243.39.*
是的。就是乐观锁。但我没有刷新取新数据回来。而是直接失败掉，让客户自己刷新。这么做是因为我们从业务上，极少会有不同的用户修改同一条纪录。
这个办法可以扩展。比如修改同一条纪录的时候，上传服务器只包含被修改的字段，不包含未修改的。降低粒度后，冲突的可能性就更低了。这也是 git 差分合并的原理吧。
【 在 licy 的大作中提到: 】
: 采用个版本号做乐观锁就行了，不用设计这么复杂
: 版本号比别人低了就刷新取新数据回来
--
修改:hgoldfish FROM 47.243.39.*
FROM 47.243.39.*