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/) Powered by Discuz! X3