这是我在要点中的问题(我希望尽可能清楚):
到目前为止一切顺利。我知道这样做相当简单:
现在,当有多个用户时出现问题。如果两个用户同时尝试发布两个不同的更新,连接到网络中的两台不同计算机,会发生什么?
是否有一些已知的策略可以解决此类问题?我打赌有。我尝试在网上看,但我真的不知道如何说出我在寻找的东西。
答案 0 :(得分:1)
这个答案是不完整的,不幸的是含糊不清,因为我仍然试图理解这里链接的论文。但是我想发布到目前为止发现的内容。
似乎有两种主要方法可以同步分散式数据复制系统。
原子性和锁定属于“悲观”算法类别,在任何一个用户发布更新时阻止所有其他用户访问。
如您所述,此方法容易受到死锁和/或饥饿问题的影响。
相比之下,乐观算法可以在不使用的情况下读取或写入数据 先验同步,基于“乐观”假设,即问题很少发生,如果有的话。更新传播 背景,偶尔的冲突在它们发生后得到修复。
http://pages.cs.wisc.edu/~remzi/Classes/739/Spring2004/Papers/optimistic-survey.pdf
根据维基百科,version vectors是用于乐观复制系统的“主要”数据结构。但是,正如您所指出的那样,在分散的上下文中存在明显的并发问题。
“如果两个用户同时尝试发布两个不同的更新,连接到网络中的两台不同的计算机,会发生什么?”
作为Brent Hoon Kang notes:
...不同的用户(或网站)进行更新极为罕见 同一时间。然而,这种罕见的事件确实在实践中发生,并且 他们的后果令人望而却步:更新可能完全失去了 具有相同ID的不同版本。实际上,这种情况就是如此 出现在sourceforge.net的CVS日志中
从Hoon的论文中,显然是一种“修复”的方法是在版本ID前加上原始节点ID和本地时间戳。然后,随着更新被“传播”(我还没有掌握),节点可以识别版本不同,尽管版本ID相同,合并它们,并创建一个新版本进行传播(如果我理解正确的话)。
但是,随着节点数量的增加,分配唯一ID会变得缓慢而复杂。
如果通过线性链接引入站点(例如,A 介绍B,B介绍C,C介绍D等,总计 所有站点名称的大小可以按数量的方式平方增长 位点。
版本向量还存在其他问题。
Hash histories提供了另一种方法来进行乐观复制。
使用HH时,节点ID不是必需的,节点可以随时加入或消失。整个网络的数据同步也比VV更快地收敛,这是我脑子里的一个原因(在论文中描述)。
哈希涉及一些版本冲突的可能性,但AFAIU现代哈希可以在实践中实现这个negligible。
Hoon的全文(相关): https://www2.eecs.berkeley.edu/Pubs/TechRpts/2004/CSD-04-1351.pdf
海报摘要: http://roc.cs.berkeley.edu/retreats/summer_02/posters/hoon_poster.pdf
由于源代码链接已关闭,我在某些细节上有点迷失,但是当我弄清楚时,我会用伪代码更新这个答案。如果我误解了您的问题,或者这对您没有帮助,我会道歉。