讨论：印象笔记的同步策略是怎么样的？

[无无无无无无无无]

小菜最近在做一个涉及多个平台的项目，和现有的产品 印象笔记 一样，有多个平台公用一个数据，涉及数据的同步问题。其中涉及的同步（sync）是怎么样的？

[ForestDB]

加一个时间戳一切皆能搞定？

[zilaishuichina]

你能举个具体的需要同步的例子么

[zilaishuichina]

A在写 B也在写 于是先提交的内容被覆盖 还是 A在写 B在读 A写完了之后B这边自动刷新

[jimette]

有多个平台公用一个数据 用同一个数据库？

[无无无无无无无无]

引用 7 楼 snake_xiongyang 的回复:

版本号即可 找个svn使用下体验下

这可能是我表达上的错误。 「你上午更新的内容，后台存进数据库」后，那中午的时候PC客户端就要「同步」数据了。 具体一点： PC客户端有数据ABC，用户打开对应的移动产品，修改A为A'，删除C，那么和服务器数据进行「同步」后，那么用户的数据会变成A'B，但是此时PC客户端还是ABC。 当用户再次打开PC客户端的时候，那么服务器就要「告知」PC客户端需要进行更新数据了。 这里的问题就是上面如何做到「告知」的问题。 当然，如果简单的做法是把PC客户端的ABC数据直接X掉，然后直接从服务器拉去数据，但这样很浪费资源。考虑到这个原因，我们才放弃这种做法的。 现在我们也开始讨论时间戳的解决方法，想听听大家的意见 :P

[zilaishuichina]

引用 10 楼 daoluanxiaozi 的回复:

引用 7 楼 snake_xiongyang 的回复:版本号即可 找个svn使用下体验下 这可能是我表达上的错误。 「你上午更新的内容，后台存进数据库」后，那中午的时候PC客户端就要「同步」数据了。 具体一点： PC客户端有数据ABC，用户打开对应的移动产品，修改A为A'，删除C，那么和服务器数据进行「同步」后，那么用户的数据会变成A'B，但是此时PC客……

o 你的意思是 怎么样只取变动了的数据 而不是整个数据全部重新取 首先 不管怎样 你肯定是需要去服务器端取数据 区别只是 取全部数据 还是取改变的数据 至于从服务器取全部数据，浪费资源，这个倒不一定， 因为你变动的数据总和有可能比文档大小要大的 这就是说 你数据库里面存 用户的操作 以及操作内容 移动产品上的操作 存进数据库 包括 时间(或者是文档版本号) 操作类型 操作内容 PC端上线 告诉服务器PC端当前的版本号 服务器 把PC端当前的版本号之后所有的操作 挨个发过来 做更新 但是举个例子 PC客户端有数据ABC PC客户端第1次改成AB PC客户端第2次改成ABC PC客户端第3次改成BC PC客户端第4次改成B 然后移动设备上线更新 你全取也只有3个字节 但是你按更新步骤来一次一次的更新 肯定不止3个字节

[ForestDB]

几个关键问题要想清楚 1、以哪一份数据为主，一般来说，这种情况应该就是云端的数据为主； 2、怎样标识更新，这就要靠时间； 3、考虑同步的效率，是否需要“增量”式的数据结构； 4、有无冲突的可能，以及冲突后的策略：a) 合并修改；b) 以最后的为主，覆盖之；当然，如果是增量式，同时又跟新频率高，那么可以认为是“无冲突”的，就不用考虑a这种复杂的情况，可以简化成b的覆盖模型，这样比较符合印象笔记这样的场合，即一个人极少可能同时开两个客户端，同时修改笔记 这样一来问题就容易得多，简化成云端和客户端 任何一个客户端的操作方式是 1、打开笔记时跟云端的时间比，如果云端的时间更新，那么就得到最新的笔记； 2、做修改的时候，“小步快跑”的方式将修改同步到云端，同时更新云端的时间戳

[ForestDB]

这里的时间，实际是个比较形象的说法，任意递增的数字，比如版本，都可以起到这样的作用。

[无无无无无无无无]

引用 9 楼 sha_jinhao 的回复:

有多个平台公用一个数据 用同一个数据库？

是的，公用一个数据库。

[无无无无无无无无]

引用 11 楼 zilaishuichina 的回复:

引用 10 楼 daoluanxiaozi 的回复:引用 7 楼 snake_xiongyang 的回复:版本号即可 找个svn使用下体验下 这可能是我表达上的错误。 「你上午更新的内容，后台存进数据库」后，那中午的时候PC客户端就要「同步」数据了。 具体一点： PC客户端有数据ABC，用户打开对应的移动产品，修改A为A'，删除C，那么和服务器数据进行「……

嗯，如果是这样的话，会更浪费资源。@ForestDB 的时间戳方法也许可以解决。我们的项目决定采用了。

[无无无无无无无无]

引用 12 楼 ForestDB 的回复:

几个关键问题要想清楚 1、以哪一份数据为主，一般来说，这种情况应该就是云端的数据为主； 2、怎样标识更新，这就要靠时间； 3、考虑同步的效率，是否需要“增量”式的数据结构； 4、有无冲突的可能，以及冲突后的策略：a) 合并修改；b) 以最后的为主，覆盖之；当然，如果是增量式，同时又跟新频率高，那么可以认为是“无冲突”的，就不用考虑a这种复杂的情况，可以简化成b的覆……

太强了！ 在你的回答中遇到一个问题，「是否需要“增量”式的数据结构」所谓的「“增量”式」放在这里是什么意思了？

[ForestDB]

刚开始可以不考虑增量，比如 客户端有数据 版本1 abcdefg 云端有数据 版本2 abcdefg hijklmn 当客户端启动时／要查看编辑数据时，先到云端看看有无新版本，发现有，就直接get新版本，然后做后续操作，比如修改数据成 abcdefg hijklmn opq rst 然后put到云端，并更新版本号为3。 当数据的规模不是很大的时候，上面的策略基本能工作，既it works（表示没有其它考量，比如性能）。 但随着产品开始成形，性能或者其他问题可能回出来，“增量”是为了解决潜在的性能问题的。 回头考虑上面的get／put操作， 版本1 abcdefg 版本2 abcdefg hijklmn 仔细观察不难看出，其实每次的修改，只是改变一小部分，比如这里的“在第一行之后增加一行‘hijklmn’”。 如果仔细分析你对一个word文档的操作，你对一个源代码文件的操作，就会发现，每次的修改，基本不会大改，都是这里添一行，那里删一行。 这样的改动，其实就是“增量” 如果这样，版本就可以这样描述 版本1 abcdefg 版本2 在版本1第一行之后添加一行“hijklmn” 而版本3就是 在版本2第二行之后添加一行“opq rst” 这样客户端在get／put的时候，实际上是get／put“增量”而不是全部的数据，当数据量大的时候，“增量”跟其相比就小很多，这样在网络带宽和效率上面，就会改善很多。 这样一来 客户端有数据 版本1 abcdefg 云端有数据 版本2 在版本1第一行之后添加一行“hijklmn” 那么当客户端get新版本时，只需要get“在版本1第一行之后添加一行“hijklmn””，就能构造出新版本了 当它做了新的修改“在版本2第二行之后添加一行“opq rst””之后，也只要put这个增量到云端形成版本3即可 这时假定还有另一客户端，它的版本是1，这时它开始操作，然后到云端一查，当前最新版本是3了，然后它就get回两个增量 append "hijklmn" append "opq rst" 就能构造出最新版本 更甚，云端对两个增量进行合并，这个客户端直接得到1到3的增量 append "hijklmn\nopq rst\n" 这就进一步优化了 到这里相信你大概明白了增量指什么，其实它的起源就是Linux下的diff／patch工具，然后就是 RCS／CSV／SVN甚至git这样的版本管理工具里都有这样的思想。 它基本上是开始优化了 上面的例子中的增量，基本上以行为单位，增加行，删除行，修改行，只是为了举例子。 可以根据自己的业务，定义合适的数据结构，然后定义合适的增量，比如以段落为单位，以逻辑块为单位，等等。

[无无无无无无无无]

引用 1 楼 ForestDB 的回复:

加一个时间戳一切皆能搞定？

终端id | 同步对象id | 时间戳 ？？是这样？

[无无无无无无无无]

引用 2 楼 zilaishuichina 的回复:

你能举个具体的需要同步的例子么

譬如： 1、今天上午用户在移动产品上更新了他的内容； 2、接下来他关掉移动产品，在中午的时候想要在web端整理自己今天上午更新的内容； 3、到了晚上，用户又打开电脑，打开PC上的客户端更新内容。 以上三点，同一个用户，都涉及了「同步」的问题。

[无无无无无无无无]

大牛支招，项目现在很紧。

[snake_xiongyang]

版本号即可 找个svn使用下体验下

[zilaishuichina]

引用 5 楼 daoluanxiaozi 的回复:

引用 2 楼 zilaishuichina 的回复:你能举个具体的需要同步的例子么 譬如： 1、今天上午用户在移动产品上更新了他的内容； 2、接下来他关掉移动产品，在中午的时候想要在web端整理自己今天上午更新的内容； 3、到了晚上，用户又打开电脑，打开PC上的客户端更新内容。 以上三点，同一个用户，都涉及了「同步」的问题。

这怎么会涉及同步的问题呢 你上午更新的内容，后台存进数据库 中午再打开 肯定是上午更新之后的内容了啊