Distributed computing 协调器失败时的两阶段提交阻塞

我正试着读报纸，但我很难通过导言。初始部分通过在事务协调器失败时将常规的两阶段提交描述为“阻塞”，为两阶段提交协议中的容错事务协调器实现建立了动机

该协调器的故障可能会导致协议阻塞，在修复协调器之前，没有进程知道结果

我的问题是——如果协调器失败，假设协调器的状态是资源管理器（或单个数据库）响应的确定函数；那么，为什么我们不能让任何其他资源管理器查询每个其他资源管理器的响应和“修复”进度呢？基本上是在超时后担任协调员的角色

---

---

这是假设单个资源管理器被建模为容错黑匣子（例如，它们是在n台机器的集群上用自己的多paxos实现实现的）

您所建议的确实是许多人用2PC所做的，您引用的同一篇论文解释了为什么第3节中的策略不正确，用兰波特的话说：

特别是，如果TM在每个RM发送了 已准备好消息，则其他RM无法知道 TM提交或中止了事务

---

用我的话来说：想象一下，原来的协调器并没有死，只是停留了很长时间（GC、死锁等等）。超时后，另一个节点将拾取松弛部分。现在，原来的协调器可以醒来并选择提交，而新的协调器可以选择中止。根据消息的交错，一些RMs最终将处于提交状态，而另一些RMs将处于中止状态，这是一种系统故障。

因此，我刚刚意识到，RMs本身被认为是有故障的资源，它们的响应可能会改变（或者简单地说，在不导致事务本身错误的情况下出错）！公平地说，如果情况不是这样，并且RMs正在运行自己的多paxos实现，那么我们可以有一个更简单的解决方法，因为他们的响应将得到保证？在这种情况下，我们可以在不确定的情况下进入第三阶段（就像你解释的那样）？抱歉，但我不明白您的提议。因此，您提到的情况下，TM可以将RM的响应视为已发送了准备好的消息，也可以不发送。那么，未来的TM将无法知道早期TM做出了什么决定，因为RM可能会被从新TM本身分割出去。但是，如果我们将每个RM视为fa如果是黑盒，那么我们知道任何新的TM都可以从RM获得响应，响应将告诉我们它们相对于事务状态的状态。然后，新的TM可以简单地轮询所有RM并在剩余事务上取得进展。这能解释问题吗？假设RMs不会失败是不现实的；例如，可能是磁盘空间不足等。即使您确实假设RMs不能失败，问题也取决于TM可以要求RMs中止或提交的事实，我不清楚的是，如果RMs不能失败，TM永远不会有任何理由中止事务。例如，如果网络拓扑已更改为包含更少的大多数情况下，就在TM“挂起”之前？任何正在进行的事务都可能必须中止，但如果新的TM确实可以访问所有RM，它可以选择提交。