Distributed transactions 在这种情况下，3PC会怎么做？

我们在分布式事务中使用3PC（三阶段承诺）。有4个节点，A、B、C、D，其中A是协调器

A从所有其他人处收到“确定”，并向他们发送“准备提交”消息

当C和D收到此消息并移动到准备状态时，B崩溃并且没有收到此消息（因此保持等待状态）

A在B上超时并向所有其他人发送中止，但只有D收到中止消息，而C在收到中止消息之前崩溃

---

现在的问题是：C在恢复后会做什么？根据，C将在故障转换后恢复时提交，而不是像D一样中止。这不会导致不一致的状态吗？或者C有某种机制来检测事务是否处于中止状态？

我认为您对B节点行为的问题有错误的假设？如果B在移动到准备状态之前崩溃，那么在重新启动后它将处于等待状态，并将被中止

---

我预计C节点将被中止，因为协调器将命令它这样做。我认为这将类似于2PC。由协调器定期检查丢失的节点是否再次可用。重新启动C时，协调器可以看到它，并将要回滚的节点推到后面，因为将重新发送中止消息。

很抱歉，输入错误。我在最后一段把B改成了C。不确定协调器是否会继续检查C并在恢复后重新发送消息。我明白你的意思，我不确定如何用不同的方式来表达。现在我发现了一篇文章。我想在此引述：“请注意，即使正在恢复的参与者处于事务的预提交状态，该参与者也无法提交事务。这是因为，如果所有站点都未处于预提交状态，则在参与者失败后，操作所有站点都可能已决定中止事务。在这种情况下，参与者必须向其他站点询问交易的最终状态。“这一点是C正在恢复。C可以通过等待命令协调器来查找状态。或者，它可以要求其他参与者了解最终状态。这取决于实现。似乎3PC不支持所有类型的多点故障。。。在我看来，你是对的。3PC本身（作为协议）无法解决这种情况。但是3PC的实现应该与状态和能够正确完成事务有关。