学习资料：
https://www.alibabacloud.com/blog/tech-insights---two-phase-commit-protocol-for-distributed-transactions_597326
在2PC中，主要的角色就是Coordinator和Participant，前者负责协调分布式事务，后者处理本地事务
2PC主要分为两个流程
Phase 1 - Prepare:
The TC writes a local<Prepare T>log and persists it. The TC sends a "Prepare T" message to all participants.
Each participant TM receives the "Prepare T" message and decides whether to commit the transaction based on its own situation:
If a TM decides to commit the transaction, it writes a<Ready T>log and persists it, and then sends a "Ready T" message to the TC.
If a TM decides not to commit the transaction, it writes an<Abort T>log and persists it, and sends an "Abort T" message to the TC. Then, the TM enters the transaction abortion process locally.
Phase 2 - Commit:
1. When the TC has received responses from all nodes or the waiting
timer times out, the TC decides whether to commit or abort the
transaction.
If all participants respond with a "Ready T" message, the TC writes a<Commit T>log and persists it, and then sends a "Commit T" message to all participants.
If the TC receives an "Abort T" response from at least one participant, or if any participant fails to respond within the timeout period, the TC writes a<Abort T>log, and then sends an "Abort T" message to all participants.
2. After the participants receive the message from the TC, they write<Commit T>or<Abort T>logs and persist them.
A participant can decide whether to abort the transaction at any time before it sends a "Ready T" message to the TC. Once this message is sent, the transaction enters the ready state, in which commit and abortion are completely controlled by the TC.
类比InnoDB的事务两阶段提交，redolog一旦准备完成后，事务提交与否就不是redolog能控制的了
To ensure this commitment, the participant must persist all the necessary information before it sends a "Ready T" message
类比InnoDB的事务，redolog和undolog的持久化必须在ready之前完成
In Phase 2, when the coordinator has written a<Commit T>or<Abort T>log, the result of the transaction is decided, that is, it will not change anymore.
类比InnoDB的事务，一旦binlog完成持久化，事务提交还是回滚已成定局
To optimize the performance of 2PC, it is crucial to reduce the persistence of critical paths and the number of remote procedure calls (RPCs). An optimization method for typical 2PC is as follows
（这段不是太get到，抛弃）
1. If the TC detects a participant failure:
If a participant fails before it sends a "Ready T" message, the TC considers that the node has aborted the transaction and starts the abortion process.
If a participant fails after it sends a "Ready T" message, it indicates that the participant has persisted the local transaction. The TC ignores the participant failure and proceeds with the transaction process.
因为持久化了本地事务，失败了也可以忽略并继续处理吗？感觉有点逻辑不自洽了
对比下看看
https://www.geeksforgeeks.org/two-phase-commit-protocol-distributed-transaction-management/
2PC缺陷：协调者的单点故障（可以使用分布式一致性算法），阻塞问题（尤其可能涉及到锁），数据不一致（网络超时导致部分节点成功或失败），没有容错可用性差（任何一个节点挂了都会导致整个系统不可用，如果每个节点都高可用就没有问题了）
所以分布式一致性算法可以解决2PC问题
