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

第一 传统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.*

这种模式其实很复杂的。
数据之间是否冲突，不是跟开发人员能决定的，很多结构是业务本身的需求决定的。尤其是涉及多用户之间交互的互联网系统，这种冲突是必须面对和解决的。

打个比方。假设业务是这样的：A在论坛上发帖pa，B查看该贴pa，业务上AB都有修改pa的权限，然后A和B都同时打开pa进行编辑。此时，必然会面临数据的冲突。

所以这个模式，并不是简单的缓存问题，感觉比缓存要复杂。缓存，我一般认为，是immutable的，大不了是版本过期然后丢弃采用新版本即可，不存在缓存跟数据库merge的问题。



【 在 hgoldfish 的大作中提到: 】
: 看了一下你的新想法，本质上还是数据缓存的管理。所以你找找缓存相关的教科书看看应该就差不多了。所谓 write-through, write-back.
: 建议你的数据结构设计成不会冲突的，无论客户端提交多少次，都不会产生重复的数据。剩下的事情都好办。
:
--
FROM 36.17.76.*