关于 2PC 提交
当一个事务需要跨多个分布式节点的时候，为了保持事务处理的 ACID 特性，就需要引入一个协调者（TM）来统一调度所有分布式节点的执行逻辑。
案例：有两个参与者和一个协调者，参与者1操作成功后，参与者2也必须操作成功。参与者1和参与者2属于两台不同的机器，现在需要跨节点提交事务，也就是分布式事务提交。
参与者成功提交事务
过程：
1》协调者给每一个参与者发起一个事务提交请求。
2》各个参与者收到请求后，给出回应：要么执行该事务成功，要么执行该事务失败。
3》如果所有参与者都回复成功执行该事务，那么协调者发起 commit 请求。
4》参与者提交事务后，给协调者一个反馈。
某些参与者提交事务失败
过程：
1》协调者给每一个参与者发起一个事务提交请求。
2》各个参与者收到请求后，给出回应：要么执行该事务成功，要么执行该事务失败。
3》参与者2执行事务失败，协调者直接给所有参与者发送回滚请求。（只要有一个参与者执行事务失败，那么都要回滚。）
4》参与者回滚事务后，给协调者一个反馈。
zookeeper的2PC提交
在 zookeeper 中，客户端会随机连接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么请求会被转发给 leader 提交事务，然后 leader 会广播事务，只要有超过半数节点写入成功，那么写请求就会被提交（类似 2PC 事务）。
所有事务请求必须由一个全局唯一的服务器来协调处理，这个服务器就是 Leader 服务器，其他的服务器就是follower。
图解说明
过程：
1》客户端发起一个写请求。
2》如果是 follower 节点接收到该请求，那么它会将该请求转发给 leader 节点处理。
3》leader 会把这个请求转化成一个事务 Proposal（提议），并把这个 Proposal 分发给集群中的所有 Follower 节点（Observer不会被转发）。
4》Leader 节点需要等待所有 Follower 节点的反馈，一旦超过半数的 Follower 节点进行了正确的反馈（执行事务成功），那么 Leader 就会再次向所有的 Follower 节点发送 commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交。
5》leader 节点将最新数据同步给 observer 节点。
6》follower 节点将结果返回给客户端。