firemail

标题: 同步冲突处理机制 [打印本页]

作者: Qter 时间: 2020-11-21 21:09
标题: 同步冲突处理机制
本帖最后由 Qter 于 2020-11-21 21:41 编辑

首先。云端不删文件，任何情况都不删，放入回收站，冲突的文件云端多版本存储。
本地同步以文件最后修改时间判断，最新的才做同步到覆盖旧的。

同步的时候，信息之间的冲突是怎么解决的比如说我把我的手机跟gmail实现了exchange的交互，我在手机离线情况下，用gmail和手机对联系人A的电话号码做修改，原号码为000000，在手机上改为123456，在gmail上改为654321。这个时候我将手机联网，gmail也同时登陆，那么哪个电话号码会被最终保留下来并同步于手机与gmail？

这需要看不同业务的需求，至少有4种方法。

以客户端为准，每次只要客户端和服务器数据冲突，将服务器数据更新。
与1相反，以服务器为准，冲突时将客户端更新。
采用某种策略将冲突的两份数据merge起来，然后服务器和客户端都采用这份数据。
将两份数据都进行保留，这时服务器和客户端都会有2条数据，evernote很多时候就这么做。

作者: Qter 时间: 2020-11-21 22:27
文件同步之冲突文件的产生及解决妙计https://blog.csdn.net/iteye_3759/article/details/82524260

什么叫同步文件冲突呢？简单的说，就是同一个文件同步双方内容不同，但是程序完全不知道该怎么进行同步，我们就说，这个文件产生了冲突。

文件同步的过程中，不可避免的会产生文件冲突。为什么？不是全部交给你搞定吗？怎么说呢？严格讲，这个还真不属于技术问题。技术高速发展，极大提升了生产力，使得大家有更多的时间躺在沙滩边晒太阳，享受美好生活，当然，也有人因此而变得更焦虑，因人而异。看起来技术无所不能，但是，有一点目前还无法解决，那就是代替人类的意志。一旦涉及到选择问题时，技术只能靠边站，决定需要人来做。这是宪法赋予我们的权利，要坚决捍卫。冲突文件大抵是产生在这样的一种情形之下，老办法，我们还是举例说明。

A电脑上目录c:\tongbu下有一个文件a.txt，B电脑上目录c:\tongbu也有一个相同的文件a.txt；这两个目录参与同步。昨天，你在A上对a.txt的内容作了修改，事后没有同步给B，这很正常，什么时候想同步才同步；今天，你在B上对a.txt的内容也作了修改，而且由于有了新的灵感，修改的内容同昨天完全不一样。之后，你想起来需要同步一下，于是A、B都启动端端(Clouduolc)上线，开始同步，端端(Clouduolc)也发现了A、B两边的a.txt文件都有了改动，但是由于两个内容的版本都是新版本，还不一样，端端(Clouduolc)就不知道到底该用A的版本同步给B呢，还是用B的版本同步给A。于是，文件冲突就在这种纠结之中产生了。

避免产生文件冲突的最好办法，是及时同步，只要有任何文件的变动，都及时同步给其他同步用户。但是，这只能是理想状态。为此搞得的精神紧张焦虑，实在没有必要。科技以人文本，技术若不提供人性化的方案，简直太没人性了。Nokia虽然今天灰头土脸，但是这句广告语真是普世真理，只可惜苹果教教主对这句话的理解更深入。

对懒人来说，端端(Clouduolc)提供了一种缺省的处理方式，那就索性产生一个新的文件就叫冲突文件。如上例子中，保留A上的a.txt，然后B上的文件改名为a (冲突文件_B 日期) .txt，然后，a.txt同步给B，a (冲突文件_B 日期) .txt同步给A，一个文件变成了两个。瞧，虽然不完美，但是成功规避了犹豫纠结、踯躇不前，用它擅长的傻办法快速搞定然后重新将选择的难题抛给人类。你自己看着办吧，要哪一个文件，或者各要一部分，反正我尽力了。

然而，对于那些作风严谨、精于控制的人来说，懒人方法导致事后处理比较繁琐，不是他们喜欢的风格。他们要高效率的立即处理。端端(Clouduolc)提供了另一种方式，即弹出一个对话框来问你，长官，请指示，是将本地的a.txt上传覆盖远端机器上的a.txt呢，还是将远端的a.txt下载覆盖本地的a.txt。端端(Clouduolc)窃笑，做选择题多累呀，还是让人类来做吧。而人类暗喜，傻瓜，我最喜欢就是指手画脚，苦活累活你去干吧！好一个双赢局面，皆大欢喜。

当然，冲突文件处理方法的选择权一如既往的属于至高无上的云管理员。他即可在创建同步目录的时候设置，也可以在之后的任何时刻更改。

欢迎光临 firemail (http://firemail.wang:8088/)