多端数据同步方案

1 Evernote

1.1 基本介绍

Evernote包括笔记(Note)、笔记本(Notebook)、标签(Tag)、资源(Resource)、搜索记录(SavedSearch)等概念。

USN(Update Sequence Number)是整个同步系统中最重要的东西,它用于标识账户中的每一次修改。每次修改后账户的USN就会+1。每一个对象(笔记本、笔记、标签等所有的东西)都会有一个USN,标识着一个对象最后一次被修改时的账户USN。例如,在某一个时刻账户的USN是100,我添加一个笔记Note1,那么账户的USN会变成101,Note1的USN也是101;然后我再添加一个笔记Note2,这时账户的USN会变成102,Note2的USN也是102,Note1的还是101。这样一来每次同步后记录一下当时账户的USN保存为lastUSN,下次同步的时候,如果账户的USN>lastUSN,说明账户中有东西被修改了。对于每一个对象,比如Note1的USN>lastUSN说明服务器端的Note1被修改了。

服务端变量

updateCount:当前账户最新(最大)的USN

fullSyncBefore:客户端执行增量同步或者完全同步的缓存截止时间。就是一个时间戳,这个变量的值通常是有东西被从账户永久性删除的时间点,或者是非法客户端USN造成一些服务器问题的时间点。

客户端变量

lastUpdateCount:上次同步获取的服务器端的updateCount变量

lastSyncTime:上次同步的时间(这个时间是从服务器上获取的,也就是服务器时间)

1.2 同步策略

同步状态

1 如果客户端从来没有和服务器同步过,就跳转到*完全同步*

2 使用NoteStrore.getSyncState(…)获取服务器端的updateCount和fullSyncBefore的值
	a 如果fullSyncBrfore > lastSyncTime 跳转到*完全同步*
	b 如果 updateCount = lastUpdateCount 说明服务器端没有更新过,跳转到*发送改变*
	c 不然就跳转到*增量同步*

完全同步

1 使用NoteStore.getSyncChunk(…,afterUSN=0,maxEntries),从服务器获取第一块数据。这里要解释两个东西。一个是数据,这里数据指所有的类型对象,但是针对于像笔记、资源这种大对象,这里指返回一些元数据(包括Guid、Title等,而不包括Content、binary、 resources这种很大的字段)。如果是标签(Tag)、搜索记录(SavedSearches)等这种小对象,那么就会返回完整的对象。还有被永久性删除的对象只返回GUID。二是关于两个参数的解释,服务器会返回USN>agterUSN的对象,但是最多返回maxEntries个,这就意味着我们可能需要通过多次获取数据,并合并才能获取到全部的数据。
	a 如果上一步返回的Chunk对象的chunkHighUSN小于Chunk对象的updateCount,保存现在这个Chunk对象,并且请求下一个Chunk,通过反复执行NoteStroe.getSyncChunk(…,afterUSN=cunkHighUSN,..)。

2 按顺序数据保存的多个Chunk对象(我们把这多个Chunk对象集合称为同步块),来构建当前服务器的状态
	a 为同步块里服务器端的标签(tags)建立一个列表(以GUID为唯一标示符),搜索同步块,按顺序把标签添加到列表,从列表中移除被标记为永久性删除(expunged)的标签(通过看guid)
		i 如果一个标签在服务器列表,但是不在客户端,那么把它添加到客户端的数据库。
		ii 如果有同名标签,但是GUID不同,按以下步骤处理
			1 如果已存在的标签有脏标记(在本地被修改过),那么说明用户在服务器创建了一个标签,另外一个客户端在离线的时候也创建了一个同名的标签。这个时候需要把他们合并, 或者报告冲突,让用户决定如何处理
			2 不然就把客户端的tag重命名一下
		iii 如果一个标签在客户端,但是不在服务端
			1 如果标签没有脏标记,或者如果它之前已经有被上传到服务器过,就把它从客户端删除
			2 不然就说明这个是客户端新建的,需要上传
		iv 如果一个标签在客户端和服务器两边都存在
			1 如果他们有相同的USN并且没有脏标记,那么他们是已经同步了的
			2 如果他们有相同的USN,但是客户端的有脏标记,那么他一会会被上传到服务器的
			3 如果服务器端的标签有比较高的USN并且客户端没有脏标记,那就把客户端的标签更新成服务端的样子(注意要处理同名冲突)
			4 如果服务端有更高的USN,并且客户端有脏标记。说明它被两端都修改过了,可以尝试合并或者报告冲突让用户决定吧
	b 对搜索记录(SavedSearches)实现相同的算法
	c 对笔记本(Notebook)实现相同的算法,如果在客户端删除一个笔记本,那么要把它所有的笔记(Notes)和资源(Resources)也都删除掉
	d 对链接笔记本(LinkedNotesbooks)实现相同算法
	e 对笔记(Note)实现相同算法,注意上面提到过的我们只获取到了没有Content的元数据,所以还需要使用NoteSrore.getNoteContent(...)来获取笔记的完整数据。另外笔记的Title是允许重名的,所以就不用担心同名冲突

3 完成了和服务器的数据合并,把服务器变量updateCount保存到lastUpdateCount,还有吧服务器的当前时间(currenttime)保存到lastSyncTime

4 转去*发送改变*

增量同步

1 用完全同步的第一步获取同步块,但是afterUSN要设置成lastUpdateCount

2 处理同步块中的列表在客户端添加或者更新数据
	a 为同步块里服务器端的标签(tags)建立一个列表(以GUID为唯一标示符),搜索同步块,按顺序把标签添加到列表,从列表中移除被标记为永久性删除(expunged)的标签(通过看guid)
		i 如果一个标签在服务器列表,但是不在客户端,那么把它添加到客户端的数据库。
		ii 如果有同名标签,但是GUID不同,按以下步骤处理
			1 如果已存在的标签有脏标记(在本地被修改过),那么说明用户在服务器创建了一个标签,在客户端也离线的时候创建了一个同名的标签。这个时候需要把他们合并, 或者报告冲突,让用户决定如何处理
			2 不然就把客户端的tag重命名一下
		iii 如果一个标签在客户端和服务器两边都存在
			1 如果客户端没有脏标记,那就把客户端的标签更新成服务端的样子(注意要处理同名冲突)
			2 如果客户端有脏标记。说明它被两端都修改过了,可以尝试合并或者报告冲突让用户决定吧
	b 对资源实现相同的算法
	c 对搜索记录(SavedSearches)实现相同的算法
	d 对笔记本(Notebook)实现相同的算法
	e 对链接笔记本(LinkedNotesbooks)实现相同算法
	f 对笔记(Note)实现相同算法,使用NoteSrore.getNoteContent(...)来获取笔记的完整数据。

3 按顺序处理需要从客户端删除的数据
	a 从同步汇集所有被永久删除(Expunge)的GUID,从客户端删除
	b 对笔记本做相同处理,注意删除笔记本时要删除所有的笔记和资源
	c 对搜索记录做相同处理
	d 对标签做相同处理
	e 对链接笔记多相同处理

4 完成了和服务器的数据合并,把服务器变量updateCount保存到lastUpdateCount,还有把服务器的当前时间(currenttime)保存到lastSyncTime

5 转去*发送改变*

发送改变

1 对每一个本地有脏标记的标签进行如下处理
	a 如果标记是新的(本地的USN没有被设置过),通过NoteStore.createTag(..)把它添加到服务器。如果服务器报告了一个冲突,客户端必须在本地处理这个冲突,产生冲突的原因是Evernote并不对同步提供锁,所以当你获取同步块之后,另外有一个客户端对服务器的内容作了部分修改,不过这个概率是在很小。如果服务端报告GUID重复了,那就在本地换一个GUID(这个概率就更小了)。
	b 如果标签被修改过的(本地的USN被设置过)使用NoteStore.updateTag(....)把服务器的内容更新,要处理同名冲突。
	c 不论是上面哪种情况,都要做一下的USN的验证。
		i 如果USN = lastUpdateCount +1说明客户端同步成功,把lastUpdateCount修改成新的USN
		ii 如果USN > lastUpdateCount +1说明同步不成功,需要重新增量同步

2 对有脏标记的搜索记录执行同样的算法

3 对有脏标记的笔记本执行同样的算法

4 对有脏标记的笔记执行同样的算法,注意客户端是使用NoteStore.createNote()必须传送有完整数据的笔记(这里注意使用createNote添加到服务器端添加的Note的GUID和本地的会不一样,就好添加成果后进行修补),在使用NoteStore.updateNote(..)的时候只需要传送有修改的字段就可以了。

2 Dropbox

Dropbox使用类diff算法(据说早期Dropbox使用的是rsync算法)将A1文件和A2文件之间的不同之处生成一个增量文件。如果Dropbox Server已经有个A1文件,那么只会上传增量文件。增量文件会被应用于A1文件,使其变为A2文件。

posted on 2016-09-24 12:26  coderland  阅读(9664)  评论(1编辑  收藏  举报

导航