Networking 跨计算机网络的原子更新同步

以下是我在要点中的问题（我想尽可能清楚地说明）：

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

到目前为止还不错。我知道这样做相当简单：

• 通过网络中的计算机已建立的连接发送更新
• 如果某台计算机在某个时间点脱机，当它重新联机时，更新的顺序和编号将允许它再次与网络同步

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

• 如果他们只是分发更新，一些节点将有一个更新，而另一些节点的堆栈中将有另一个不同的更新，因此我失去了一致性
• 如果我实现某种形式的锁定机制，在发布更新之前，我尝试锁定所有节点，我可能会引发各种与饥饿相关的问题
• 我想选择一台计算机作为主机，让所有的用户都连接到这台计算机上，但是我怎么才能选择哪一台是主机呢？出现以下问题：
  • 我如何选择大师
  • 这也应该是动态的。如果主机脱机会发生什么情况
  • 由于可能存在错误的连接，并非所有节点都会看到一个节点处于联机状态，即使该节点处于联机状态：在极少数情况下，主计算机（它处于联机状态并可以连接到所有其他计算机）可能会被其中一台视为脱机。然后呢

---

是否有一些已知的策略来解决这类问题？我打赌有。我试着在网上查找，但我真的不知道如何表达我要查找的内容。

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

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

悲观的

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

正如您所提到的，这种方法容易出现死锁和/或饥饿问题

乐观的

与此相反，乐观算法允许数据在没有任何限制的情况下读取或写入 先验同步，基于“乐观”假设，即问题很少发生（如果有的话）。更新在中传播 背景和偶尔的冲突在它们发生后是固定的

根据维基百科的说法，是用于乐观复制系统的“主要”数据结构。然而，正如您所注意到的，在分散的上下文中存在一个明显的并发问题

如果两个用户同时尝试发布两个不同的更新，并连接到网络中的两台不同计算机，会发生什么情况

作为布伦特·胡恩·康：

。。。不同的用户（或站点）在同一时间进行更新是极为罕见的 同时。然而，这种罕见的事件确实在实践中发生，而且 它们的结果是禁止的：更新可能会完全丢失 具有相同id的不同版本。事实上，这样的情况是 出现在sourceforge.net的CVS日志中

从Hoon的论文中，显然“修复”这一问题的一种方法是在版本ID前面加上原始节点ID和本地时间戳。然后，当更新被“传播”（我还没有掌握这一点）时，节点可以识别版本不同（尽管版本ID相同），合并它们，并创建一个新版本来传播（如果我理解正确的话）

但是，随着节点数量的增加，分配唯一ID变得缓慢而复杂

如果站点是通过线性链接引入的（例如 介绍B，B介绍C，C介绍D，等等），总计 所有站点名称的大小都可以按用户数量二次增长 地点

版本向量还有其他问题

提供执行乐观复制的替代方法

使用HH，不需要节点ID，节点可以随时加入或消失。网络上的数据同步也比VV的收敛速度更快，这是我无法理解的原因（在论文中描述）

哈希涉及到版本冲突的一些可能性，但AFAIU现代哈希在实践中可以做到这一点

胡恩的完整论文（相关）：

海报摘要：

---

由于源代码链接已关闭，我对一些细节有点茫然，但我会在找到答案后用伪代码更新这个答案。如果我误读了您的问题或这没有帮助，我深表歉意。

这正是我想要的！我真的很感谢你的帮助！其他的东西可能有用-。上的许多实现