我正在尝试阅读Paxos Commit论文，并且在试图超越简介的同时苦苦挣扎。初始部分通过将事务协调器失败时的常规两阶段提交描述为“阻塞”，从而为两阶段提交协议中的容错事务协调器实现提供了动力
该协调器的故障可能导致协议被阻塞，直到没有过程知道结果为止，直到修复该协调器为止。
我的问题是-如果协调器失败，则假设协调器的状态是资源管理器（或各个数据库）的响应的确定性函数；那么为什么我们不能简单地让任何其他资源管理器向其他每个资源管理器查询它们的响应和“修复”进度呢？超时后基本上由协调员担任。
这是假设将各个资源管理器建模为容错的黑匣子（例如，它们是在n台机器的群集上以自己的多用户实现来实现的）
答案 0 :(得分：1)
您的建议确实是许多人对2PC所做的事情，您所引用的同一篇论文也用Lamport的话解释了为什么在第3部分中该策略不正确：
尤其是，如果TM在每个RM发送了一个 准备好的消息，则其他RM无法知道是否 TM已提交或中止了交易
以我的话：想象原来的协调器并没有死，而是停留了很长时间（GC，死锁，等等）。超时后，另一个节点将接走松弛。现在，原始协调器可以唤醒并选择提交，而新协调器可以选择中止。根据消息的交织，某些RM最终会处于提交状态，而其他RM则处于异常终止状态，这是系统故障。