问题描述
我读了一篇帖子，说:
我完全同意.
但是，如果有人可以解释此问题的确切原因，那就太好了.如果我要通过微服务实现两阶段提交，将会遇到什么问题?
But it would be great if someone here can explain the exact reason for this.What would be the issues I'm going to face if I'm implementing 2-phase commit with microservices?
预先感谢
推荐答案
避免两阶段提交的主要原因是，事务协调器是一种独裁者，因为它告诉所有其他节点要做什么.通常，事务协调器嵌入在应用程序服务器中.在第一阶段或准备阶段之后，事务协调器或应用程序服务器关闭时，就会发生问题.现在，参与节点不知道该怎么办.他们不能承诺，因为他们不知道其他人是否对协调员回答否"，也无法回滚，因为其他人可能对协调员说是".因此，直到协调员在15分钟后(例如)返回并完成第二阶段，参与的数据存储将保持锁定状态.这抑制了可扩展性和性能.在第一阶段之后协调器的事务日志损坏时，会发生更糟的事情.在这种情况下，数据存储将永远保持锁定状态.即使重新启动进程也无济于事.唯一的解决方案是手动检查数据以确保一致性，然后删除锁.这些事情通常发生在高压情况下，因此肯定是巨大的运营开销.因此，传统的两阶段提交不是一个好的解决方案.
The main reason for avoiding 2-phase commit is, the transaction co-ordinator is a kind of dictator as it tells all other nodes what to do. Usually the transaction co-ordinator is embedded in the application server. The problem happens when after the 1st phase or prepare phase the transaction co-ordinator or the application server goes down. Now, the participating nodes don't know what to do. They cannot commit because they don't know if others have replied to the co-ordinator with a "no" and they cannot rollback because others might have said a "yes" to the co-ordinator. So, until the co-ordinator comes back after 15 minutes (say) and completes the 2nd phase, the participating data stores will remain in a locked state. This inhibits scalability and performance. Worse things happen when the transaction log of the co-ordinator gets corrupted after the 1st phase. In that case, the data stores remain in the locked state forever. Even restarting the processes won't help. The only solution is to manually check the data to ensure consistancy and then remove the locks. These things usually happen in a high pressure situation and therefore it's definitely a huge operational overhead. Hence the traditional 2-phase commit is not a good solution.
但是，在这里应该指出的是，某些现代系统(如Kafka)也实现了两阶段提交.但这与传统解决方案的不同之处在于，这里的每个经纪人都可以充当协调者，因此Kafka的领导者选举算法和复制模型可以缓解传统模型中提到的问题.
However, it should be noted here that some of the modern systems like Kafka have also implemented a 2-phase commit. But this is different from the traditional solution in that here every broker can be a co-ordinator and thus the Kafka's leader election algorithm and the replication model alleviate the issues mentioned in the traditional model.
这篇关于为什么两阶段提交不适用于微服务架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！