应用错误收集

这是我在要点中的问题（我希望尽可能清楚）：

我有一组计算机，以点对点方式连接，因此没有中央服务器。
每台计算机有时（但实际上不常，正常运行时间应该在0.98左右）可以脱机。此外，有时可能会丢失连接，或者由于某种原因，两个节点可能无法连接。但大多数情况下，连接将起作用并且相当稳定。
每台计算机都保留一堆更新的副本。更新按渐进顺序编号。
在任何时候，外部用户都可以连接到网络中的任何计算机并发布（已签名，因此更新可通过网络验证）更新。
然后应该通过网络分派更新，并将其添加到每台计算机的更新堆栈中。

到目前为止一切顺利。我知道这样做相当简单：

现在，当有多个用户时出现问题。如果两个用户同时尝试发布两个不同的更新，连接到网络中的两台不同计算机，会发生什么？

如果他们只是分发更新，一些节点将有一个更新，而另一些节点将在其堆栈中有另一个不同的更新，所以我失去了连贯性。
如果我实现某种形式的锁定机制，在发布更新之前，我会尝试锁定所有节点，我可能会遇到各种与饥饿相关的问题。
我考虑选择一台计算机作为主计算机并让所有用户连接到该计算机，但是我如何选择哪一台计算机是主计算机？出现以下问题：
- 如何选择主人？
- 那也应该是动态的。如果主站下线会发生什么？
- 由于可能出现连接错误，并非所有节点都会看到一个在线节点，即使它是：在非常罕见的情况下，可能会发生在线并可以连接到所有其他计算机的主计算机被其中一个人视为离线。那么会发生什么？

是否有一些已知的策略可以解决此类问题？我打赌有。我尝试在网上看，但我真的不知道如何说出我在寻找的东西。

这个答案是不完整的，不幸的是含糊不清，因为我仍然试图理解这里链接的论文。但是我想发布到目前为止发现的内容。

似乎有两种主要方法可以同步分散式数据复制系统。

原子性和锁定属于“悲观”算法类别，在任何一个用户发布更新时阻止所有其他用户访问。

如您所述，此方法容易受到死锁和/或饥饿问题的影响。

相比之下，乐观算法可以在不使用的情况下读取或写入数据先验同步，基于“乐观”假设，即问题很少发生，如果有的话。更新传播背景，偶尔的冲突在它们发生后得到修复。

根据维基百科，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。

由于源代码链接已关闭，我在某些细节上有点迷失，但是当我弄清楚时，我会用伪代码更新这个答案。如果我误解了您的问题，或者这对您没有帮助，我会道歉。