2PC两阶段提交协议

一句话总结：2PC两阶段提交协议应用于分布式事务场景，解决分布式多个系统间数据的一致性，如数据库XA机制。

 

背景：

假设有两个系统A和B，同一个原子业务，举个经常使用的转帐例子，A系统加1000元，B系统相应减1000元，这时若A执行成功了，B执行失败了，对业务来讲确定出问题了。这里的问题出在系统A不感知B的状态，B也不感知A。对于分布式系统，须要一个协调者来感知每一个系统的执行状态。这个协调者能够由应用或数据库/缓存的Agent来承担均可以。

 

2PC两阶段提交协议：

 

你们不要将两阶段提交想的复杂，事实上，这个协议很简单，prepare阶段参与者只是执行事务，但不提交，此时已能知道可否成功执行，并将此状态反馈给协调者。协调者收到都成功，则通知全部参与者commit。若只要有一个反馈失败，则通知全部参与者rollback。协调者在commit阶段发出commit或rollback通知后就无论了。

 

延伸思考：

上面描述的是正常流程，生产环境还要全面考虑各类异常场景。

一、协调者节点挂了

此场景比较主流的方案是选举机制，首次即经过选举决定谁是协调者，当协调者挂掉后从新选举。

二、commit阶段出现部分失败

2PC协议在commit阶段发出commit或rollback通知后就无论了，若此时因为网络或系统缘由，A执行commit/rollback成功，B执行失败，仍是会出现数据不一致。此场景就须要考虑3PC、另外一个独立Agent进程、超时机制等来确保事务不管如何都会被执行。

 

备注：网上不少有说一个问题是同步阻塞，性能不行。我以为大多数场景特别是针对事务数据一致性的场景对性能要求并不高，不应把这个做为问题。毕竟作1230六、微信、抖音、王者荣耀等这些高并发实时性强项目的场景很少，普通数千并发实时要求也不强以当前服务器性能彻底hold的住的。

 

引用：

 https://en.wikipedia.org/wiki/Two-phase_commit_protocol

 

注：图片来源于网络，侵删。