这些需要分为几个部分。 ## 实时数据的同步 网络连接状态表（到各个个人设备的路由信息）、信任关系表、文件索引之类的这些需要时刻与网络保持同步的信息。这些信息构成了分布式个人网络的基础设施，其他的资源很大程度上都需要依赖于这些信息的存在才能正常工作（尤其是一些原子操作，例如文件差分更新），所以这部分的数据通常需要设备之间的直接与间接（隧道）网络连接来进行直接的联系（RPC形式）。这些数据是一旦发起了更改，就需要立刻将更改推送到全部在线终端。而已经处于离线状态的终端在恢复上线时需要查询是否有需要同步的实时同步信息。只有在完成同步之后才应完成上线动作。 TODO：多方同步导致的脑裂问题如何解决？ ## 常用的完全同步的数据 一些常用的，尺寸不会特别大的，可以在个人用户的所有终端之间同步的数据。例如用户偏好设置、一些笔记内容。这些数据的实时性要求不会太高，因此可以定时/基于通知和推送拉取来同步。这些数据因为尺寸不大但使用频繁，所以总是全量同步的。 ## 常用的间接同步的数据 一些常用的，但尺寸可能会比较大的数据，比如一些个人的数据库，正在工作的一些项目文件。 这部分数据正常情况下是托管在用户的某个个人存储设备上，按需从网络中拉取同步的。本地如果有修改，则第一时间通知到个人存储设备，对应文件在远端的一个终端上存在修改版本。在这部分可能会需要一些二进制差分更新的能力。 实际上，一份文件并不是只能托管在一个个人存储设备上。可以指定多个个人存储设备来托管相同的一份文件。这样之后在拉取文件的时候，就可以把相同的数据从多个位置同时拉取来加速文件的获取了，有点类似BT的工作方式。配合上面的二进制差分更新的能力，还可以更快的取得已经产生的更新部分。 其他终端如果需要同步，则可以暂时不等待个人存储设备完成同步，而是直接从发起了远端修改的设备上直接拉取同步内容。 差分传输需要在提供给用户前先完成差分版本的合并，以便用户使用同步回来的文件。但考虑到其他客户端的同步进度可能跟不上，需要保留最近的一些差分版本数据用来加速传输。如果一个客户端落后版本实在太多，在所有客户端都找不到最近的这些差分版本数据，则直接全量拉取覆盖掉本地版本。 ## 大型数据 大型数据，比如归档的文件数据，不会经常产生修改的文件数据，犯了仓鼠症屯的各种奇奇怪怪的媒体文件、压缩包。这些文件通常来说是为了自用或者给其他人分享的，就有点网盘的那种意思。 这些数据通常是放在一个或者多个个人存储设备上（传输方式是整体传输加少量的差分传输）。使用上面提到的类似BT的工作方式来完成传输。这些数据总是全量传输的。 用户可以指定在多个设备上存储这些文件，并且可以指定是否允许有传出流量（指定传给自己或者也允许传给他人，还是只允许传入当异地备份）。 ## 链接数据 基于第三方存储服务的数据。这些实际上可以利用外链的形式来做。存储后端的表示方式就用对象数据库的对象链接来指向目标。解析外部链接的工作也是由对象数据库本身提供的功能来做就好。