我看过一篇文章说:
We can not implement traditional transaction system like 2 phase commit in micro-services in a distributed environment.
我完全同意这一点。
但是，如果这里有人可以解释其中的确切原因，那就太好了。 如果我使用微服务实现两阶段提交，我将面临哪些问题？
提前致谢
最佳答案
避免两阶段提交的主要原因是，事务协调器是一种独裁者，因为它告诉所有其他节点该做什么。通常事务协调器嵌入在应用服务器中。当在第一阶段或准备阶段之后事务协调器或应用程序服务器出现故障时，就会出现问题。现在，参与节点不知道该怎么办。他们无法提交，因为他们不知道其他人是否已对协调员回复“否”，并且他们无法回滚，因为其他人可能已对协调员说"is"。因此，直到协调员在 15 分钟(比方说)后回来并完成第二阶段，参与的数据存储将保持锁定状态。这抑制了可扩展性和性能。当协调器的事务日志在第一阶段后损坏时，会发生更糟糕的事情。在这种情况下，数据存储将永远处于锁定状态。即使重新启动进程也无济于事。唯一的解决办法是手动检查数据以确保一致性，然后解除锁定。这些事情通常发生在高压情况下，因此这绝对是一个巨大的运营开销。因此，传统的两阶段提交并不是一个好的解决方案。
但是，这里需要注意的是，一些现代系统如 Kafka 也实现了两阶段提交。但这与传统的解决方案不同，这里每个broker都可以是协调者，因此Kafka的leader选举算法和复制模型缓解了传统模型中提到的问题。
关于microservices - 为什么两阶段提交不适合微服务架构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55249656/