Database 两阶段提交

我相信大多数人都知道什么是2PC（两阶段提交协议），以及如何在Java或大多数现代语言中使用它。基本上，当您有2个或更多的数据库时，它用于确保事务同步

假设我有两个DBs（A和B）在两个不同的位置使用2PC。在A和B准备提交事务之前，两个DBs都将向事务管理器报告它们准备提交。因此，当事务管理器被确认时，它将向a和B发送一个信号，告诉他们继续

我的问题是：假设A收到信号并提交了交易。一旦一切都完成了，B也要这么做，但有人拔下了电源线，导致整个服务器关闭。当B重新联机时，B将做什么？B是怎么做到的

---

请记住，A已提交，但B未提交，我们正在使用2PC（因此，2PC的设计停止工作，不是吗？

在两阶段提交上

两阶段提交并不能保证分布式事务不会失败，但它可以保证它不会在TM不知道的情况下以静默方式失败

为了让B将事务报告为准备提交，B必须将事务置于持久存储中（即，B必须能够保证事务在所有情况下都可以提交）。在这种情况下，B已持久化事务，但事务管理器尚未收到来自B的确认B已完成提交的消息

当B重新联机时，事务管理器将再次轮询B，并要求其提交事务。如果B已经提交了事务，它会将事务报告为已提交。如果B还没有提交事务，那么它将提交，因为它已经持久化了事务，因此仍然能够提交事务

为了使B在这种情况下失败，它必须经历灾难性的失败，丢失数据或日志条目。事务管理器仍然会知道B没有报告成功的提交。1

在实践中，如果B不能再提交事务，则意味着将B取出的灾难导致了数据丢失，并且当TM要求B提交其不知道或认为处于可提交状态的TxID时，B将报告错误

因此，两阶段提交并不能防止灾难性故障的发生，但可以防止故障被忽略。在这种情况下，如果B无法提交，事务管理器将向应用程序报告一个错误

应用程序仍然必须能够从错误中恢复，但是事务不能在应用程序不知道不一致状态的情况下以静默方式失败

语义

• 如果资源管理器或网络在第1阶段出现故障，则 事务管理器将检测到致命错误（无法连接到 资源管理器），并将子事务标记为失败。当 网络恢复后，它将中止所有网络上的事务 参与的资源管理人员

• 如果资源管理器或网络在第2阶段出现故障，则 事务管理器将继续轮询资源管理器，直到 它回来了。当它重新连接回资源管理器时 它将告诉RM提交事务。如果RM返回 “未知TxID”沿线的错误TM会意识到 RM中存在数据丢失问题

• 如果TM在第1阶段下降，则客户端将阻塞，直到 TM将返回，除非它超时或由于以下原因收到错误： 网络连接中断。在这种情况下，客户会意识到 错误，可以重试或启动中止本身

• 如果TM在第2阶段出现故障，则它将阻止客户端，直到 TM回来了。它已经将该交易报告为 可提交且不应向客户提供致命错误， 尽管它可能会阻塞，直到TM恢复。TM仍将继续运行 使事务处于未提交状态，并将轮询RMs 当它重新出现时提交

资源管理器中的提交后数据丢失事件不由事务管理器处理，而是RMs恢复能力的一个功能

两阶段提交不能保证容错性（请参阅解决容错性的协议示例），但它可以保证分布式事务的部分故障不会被忽略

请注意，这种失败也可能会丢失以前提交的事务中的数据。两阶段提交不能保证资源管理器不会丢失或损坏数据，也不能保证灾难恢复过程不会出错

---

我认为三阶段提交是一种更好的方法。不幸的是，我还没有找到任何人实现这样的技术

以下是上述条款的基本部分：

2PC的根本困难在于，一旦协调人做出了提交的决定并将其传达给了一些副本，这些副本就直接按照commit语句进行操作，而无需检查其他副本是否都收到了该消息。然后，如果提交的复制副本与协调器一起崩溃，则系统无法知道事务的结果是什么（因为只有协调器和获得消息的复制副本可以确定）。由于事务可能已经在崩溃的复制副本上提交，因此协议不能悲观地中止，因为事务可能具有无法撤消的副作用。类似地，协议不能乐观地强制事务提交，因为最初的投票可能是中止

这个问题主要通过在2PC上增加一个额外的相位来解决，毫不奇怪，它为我们提供了一个三相共扼流圈