这种跟以前的没啥区别吧

跟后端的缓存也没啥区别


【 在 misslost 的大作中提到: 】
: 现在的前端都是大前端，后端只是通过接口传送数据，前端也可以使用本地数据库（app或者web）来保存数据或者缓存数据。这就涉及到客户端和服务端的数据同步问题。这方面，前后端的数据同步和缓存，有没有比较成熟的算法或者设计模式，或者开源的参考的应用？
: 谢谢
--
修改:licy FROM 36.112.190.*
FROM 36.112.190.*

我没说清楚，我详细说下想法。

第一 传统web模式。以简单的web 论坛发帖的业务来举例。传统web模式步骤为
-    web页面，创建 帖子
-    js调用ajax接口，向服务端发送json数据（后端的controller/service/dao进行分层处理）
-    根据返回结果，向用户提示：发帖成功。

第二 自动异步处理模式。现在SPA框架下，前端是一个独立的客户端app了。那么，可以考虑用异步处理模式：
-    app内，创建 帖子
-    js调用 客户端业务处理接口，保存数据到客户端DB中，不等待网络响应可马上返回用户。
-    （浏览器服务器之间的数据同步层进行异步的处理）客户端DB数据会适时的跟服务端同步。
-    将客户端DB中的状态展示到ui上，向用户提示： 帖子等待同步，帖子同步成功，帖子同步失败。

第二种模式的特点：
-    ui的响应快，不需要等待网络。
-    网络数据，B、S端的同步，是异步自动进行的。客户端不需要设计专门的ajax接口。如果底层数据同步模块做成通用的，客户端应用的开发不需要关注网络通信的问题了。
-    适用于普通的互联网数据，不适用于强事务的关键数据。

其实 跟数据库主从复制等算法很相似。

那么，问题来了，这方面的设计模式和算法，有没有可以参考和学习的项目呢？

谢谢

【 在 licy 的大作中提到: 】
: 这种跟以前的没啥区别吧
: 跟后端的缓存也没啥区别
:
--
FROM 36.17.76.*

看了一下你的新想法，本质上还是数据缓存的管理。所以你找找缓存相关的教科书看看应该就差不多了。所谓 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.*