OP 在那个贴子里提到的存储在用户本地的信息集合,有些类似 Tim Berners Lee 搞的 Solid (
https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) )?不过它更强调的是不同节点之间的互联。
---
有关同步的问题,我有过类似的想法:定义一种协议,它可以描述确定两个节点 A 和 B 之间的数据可以如何同步,并且
- A 和 B 不一定要相等,可以是 A 的子集和 B 的某个子集进行同步
- 比如 A 是一个人手机上的各种类型数据的集合,B 是一个服务器,那 A 只需要把照片这个子集和 B 里面属于 A 的部分同步
- 这个模式已经很常见了,但还没有发现有通用协议去规定它
- 同步当然要是增量的,但基于文件的同步不太靠谱,因为我们没法假定同步工具支持增量同步,也没法假定数据库到底是以何种方式存储的
- Event Sourcing 是个思路:每次修改会产生一条记录,当前数据是所有记录执行后的一个快照。这个设计类似 Flux 或者 Git ,所以很自然地,如果同步双方的记录日志分叉了,还可以尝试 merge
- 继续从 Git 思路出发,客户端和服务端是多对多关系,甚至没有服务端的概念,因为服务端本身也可以作为中继,同步到上游数据库
- 如何避免环出现呢?
- 不知道 OP 用不用 iCloud ,其实 iCloud 就像时刻连接着的一根线,把设备的数据和苹果的服务器做 iTunes 同步。这里同步的是数据库而不是文件( iCloud 云盘是后来才有的),所以后来它们还开放了 CloudKit 这个东西
- 苹果的自带软件和若干第三方软件都偏好用 iTunes 风格的数据库而不是文件夹存数据。我喜欢这种方式,因为数据库比文件要结构化得多,能存更多元数据,读写同步效率也都更高
- 但并不是所有数据都能放到数据库里,比如很大的照片或录像,它们适合存放在单独的文件里作为 Blob. 如果把这些数据库和 Blob 打包并规范化(开发一个统一 API 操作),那会十分方便,并且可以和第一点提到的协议结合,软件的各个小数据库其实是系统大数据库的一部分(有点像 Windows 注册表了?)
- 某些文档数据库已经自带了管理 Blob 到文件的功能
- 由于数据结构高度统一,快照、备份、回滚这些功能都变得很容易,可以用类似 zfs send/receive 的方法轻松备份和加密