仔细阅读the online documentation后，我仍然有很多关于MongoDB中两阶段提交的问题。
在从故障情景中恢复部分中，为什么只有两类故障？在我的思想中，失败可能发生在任何这些步骤中，所以这里应该有两个以上的类。例如，在更新帐户A后，（在对两个帐户应用交易部分中），数据库服务器失败。这意味着账户A在账户B没有发生任何事情的情况下损失了一些钱。我们会有不一致的交易吗？
答案 0 :(得分：7)
当应用程序或数据库在将事务应用于A并将事务应用于B之间突然崩溃时，全局事务集合中仍将存在state:"pending"的事务。您在崩溃后运行的恢复脚本应该注意到这一点，检查这两个帐户，并在一个帐户中看到有待处理的事务，而不是另一个帐户。它现在知道要么回滚事务还是试图完成它所需要知道的一切。
是的，编写一个智能的恢复脚本并不容易。但是，不是为他们设计的数据库系统中的事务总是很难。有时您可以通过设计文档来解决MongoDB中的事务，这些文档需要一起更新的字段始终位于同一文档中，但并不总是有理由这样做。当您的用例绝对需要事务时，请保护您的理智并使用关系数据库。
答案 1 :(得分：3)
在我的想法中，任何一个步骤都可能发生失败，所以这里应该有两个以上的课程。
这里要记住的关键是文档不是两阶段提交的权威指南，实际上在MongoDB中技术上不可能进行两阶段提交，如果你想要执行它们，我强烈建议你获得ACID技术。
您必须记住，由于某些故障情况不属于服务器本身，因此您无法对抗某些故障情形。相反，两个阶段提交的整个存在只是客户端，因此与TTL监控相比，它非常脆弱。
更新帐户A后数据库服务器失败。这意味着账户A在账户B没有发生任何事情的情况下损失了一些钱。我们会有不一致的交易吗？
为了支持Philipps回答，在这种情况下，帐户A和B之间的原始交易仍然有待处理，只有在帐户B更新后才会将其移至已完成/已完成。
这意味着交易无法在完成之前标记为已完成。
不是将MongoDB用于不是真正设计的场景，而是建议使用专为您的场景设计的内容。
答案 2 :(得分：0)
在线文件可能并不完美。 实际上你需要回滚A和B上的操作