避免两阶段提交的主要原因是，事务协调器是一种独裁者，因为它告诉所有其他节点该做什么。通常事务协调器嵌入在应用程序服务器中。当在第一阶段或准备阶段之后，事务协调器或应用程序服务器出现故障时，就会出现问题。现在，参与节点不知道该怎么做。他们无法提交，因为他们不知道其他人是否以“否”回答了协调员，并且他们无法回滚，因为其他人可能对协调员说了“是”。所以，直到协调ATOR 在 15 分钟后返回（例如）并完成第二阶段，参与数据存储将保持锁定状态。这会抑制可伸缩性和性能。当协调器的事务日志在第一阶段之后损坏时，会发生更糟糕的事情。在这种情况下，数据存储将永远处于锁定状态。即使重新启动进程也无济于事。唯一的解决方案是手动检查数据以确保一致性，然后删除锁。这些事情通常发生在高压情况下，因此这绝对是一个巨大的运营开销。因此传统的两阶段提交不是一个好的解决方案。

但是，这里应该注意的是，一些现代系统（如 Kafka）也实现了两阶段提交。但这与传统解决方案不同，因为在这里每个代理都可以成为协调者，因此 Kafka 的领导者选举算法和复制模型缓解了传统模型中提到的问题。

需要注意的一些事项，并给出一些背景：

null

这里的“我们不能”实际上意味着“这是一个坏主意，我不想，如果我承认这种可能性，那么我可能无法说服你不要坚持”。

当然，您可以跨微服务实现两阶段提交，但是：

• 两阶段提交需要在可以参与事务的每个服务中进行大量的开发工作，
• 它会导致客户端之间的大量争用，这些争用随着服务器之间的通信延迟而增长;和
• 所有涉及的服务都必须就许多协议、配置、部署和其他细节达成一致，这些细节决定了两阶段提交的实际工作方式。

这些问题很难在具有专用网络的同地服务器上的几个紧密耦合的服务中进行管理。在更异构的环境中，具有更多的服务器和更高的延迟，这是微服务部署的特征，这变得更加困难。