基于funambol ds 的云同步服务研究(二)-同步原理分析

来源:互联网 发布:韩国乐天免税店有mac吗 编辑:程序博客网 时间:2024/04/30 19:23
 

一、 同步包含单个客户端设备的数据同步, 云端的数据同步以及多客户端之间的数据同步.在实际操作中, 多个客户端之间数据会不停地操作变化, 以及云端数据的随时更新,  如何能保持这些数据的一致性, 不至于产生错乱呢? 乍看有点棘手, 这里我们需要去仔细分析下, 把各种情况考虑清楚.

   无论是单个客户端或是多个客户端的同步, 是单个账号多设备还是单设备多个账号的数据同步, 都可简化分为客户端和云端的同步, 区别只是同步的时间和次数的差异,  把这两端的关系分析处理好, 才能保持数据同步的一致性.

 

 二、funambol的同步流程:

1. funambol的同步矩阵图表

Source A 代表的是客户端的源数据

Source B 代表的是服务端的源数据

A: 代表数据替换为A方客户端; B代表数据替换为B方服务端;

D:代表删除; C:代表冲突; X: 代表不做任何操作

图1

  这是funambol的同步处理规则, 基本是考虑到了所有情况, 但是在实际中会发现, 仅仅按照上面的矩阵图处理是不够的, 如果存在冲突数据, 该怎么去处理, 是该遵循怎样的规则, 下面会分析, 还是先继续看完funambol的同步处理流程.

 2.同步修改检测模型

图2

同步当中, 必然会存在修改的数据, 如果两端发生修改, 该怎么去处理, 这是funambol的修改检测机制:

A – 我们把它可以看作是客户端的数据.

B – 把它看作是服务端的数据.

Am – 客户端修改的数据.

Bm – 服务端修改的数据.

AmBm – 客户端和服务端都已修改的数据.

(A-Am)Bm – 在客户端没有修改, 但在服务端修改的数据.

Am(B-Bm) – 在服务端没有修改, 但在客户端修改的数据.

 考虑得比较周全, 源码也是按照此图先做数据分析, 然后再执行更新. 这样会比较清晰, 把数据归类, 确定是在哪边执行更新操作.

 

3. 数据关联映射 

  上面讲到的是funambol同步的主要处理流程, 大致了解后, 再来看看, 还有个重要的问题, 客户端的数据和云端的数据是怎么关联起来的? 是把所有数据抛过去, 再把所有属性一一比对标识?  还是可以通过唯一标识去关联呢?  如果使用唯一标识, 该怎样去建立, 能否正确匹配? 每种方式都有利有弊, 先来看看funambol的数据关联机制是如何实现的:

图3

LUID (Locally Unique Identifier): 代表的是客户端数据唯一标识.

GUID (Global Unique Identifier): 代表的服务端数据唯一标识.

   如图3所示,  通过LUID和GUID的映射数据表, 我们就能够正确的找到关联的数据. LUID由客户端生成, GUID由服务端所生成. 客户端生成的标识可以用自增长的ID吗? 服务端是可以, 但客户端不行, 因为云端只有一个, 而客户端会有多个. Funambol的客户端是采用时间戳作为唯一标识的. 每种方式都有其利弊, 这种设计方式也存在一个缺陷, 当客户端重装系统, 从SIM卡导入联系人, 再进行同步时, 生成新的时间戳标识, 就无法关联到以前同步的数据, 会造成重复. 当然, 这种操作方式算是特殊情况, 可以包容. 解决的方法可以在客户端增加全属性比对的合并功能.

 

 

4. 同步时间标记

  以上讲的是数据的操作以及关联匹配处理, 这是非常核心的内容, 但是仅有这些还不够, 在实际操作中, 如何能保证每次同步能够获取正确的数据? 同步后的数据下次同步不会再重复呢? 不同客户端同步的数据, 彼此又是如何都能检测得到呢? 要解决这些问题, 还需要有个时间标记, 数据同步协议里面已经考虑到这些, 提供了两个时间戳标记, 上次同步时间和当前同步时间:

<Anchor xmlns="syncml:metinf">

    <Last>1325125990</Last>

    <Next>1325126100</Next>

</Anchor> :

 

图4

   参考图4, 客户端和服务端进行同步时, 会先由客户端发送时间标记, 服务端进行检测, 如果上次同步时间相符, 则会根据当前同步时间去匹配同步数据, 传送给客户端; 如果上次同步时间不符合, 则服务端会传送508指令给客户端, 要求客户端进行全同步. 存在两个流程走向, 这样是为了确保差异化同步时, 数据的正确性.

 

 

三、实际同步业务场景 

  上面图1的同步矩阵图是funambol的建立的一个框架,  在这个基础上, 可以进行改造, 去适应我们实际的业务应用.

  下面的图5基本涵盖了所有业务场景, 同步结果的前提是以客户端的数据为最高优先级, 如果以服务端的数据为最高优先级, 同步结果则相反, 虽然包含16种业务场景, 但只要确立好规则, 处理起来并不复杂.

图5

 

 

  同步看起来是件简单的事情, 但实现角度来讲, 并不简单, 牵涉到数据的增删改, 操作的时间与次数, 数据的正确性与完整性, 要把它做好, 是要花费一定的精力. 把同步原理分析理解清楚,  有利于对funambol ds框架的使用与源码的研究.