小白学分布式程序开发8-二阶段提交的缺点

上次我们讲了二阶段提交，今天我们就接着来讲讲二阶段提交的缺点

1.同步阻塞问题

执行过程中，所有参与节点都是事务阻塞型的。
当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

举例：接上一篇的例子，如果Jim是打电话到小白的宿舍里，小白用宿舍的公用电话来接，那么宿舍里的其他人想打电话只有等在小白后面了。

2.单点故障

由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

举例：如果组织者Jim在和小白、小明沟通过程中突然失忆（这个例子有点衰~），那么小白、小明会一直傻傻地等着回复，而不会去做任何其他事情。

3.数据不一致

在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。
而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据一致性的现象。

举例：小白、小明都先回复了Jim去参加爬山活动，Jim先通知小白活动成行后，遇到线路故障，Jim无法通知到小明了，最后导致小白去参加活动了，小明因为没有收到通知没去参加的情况。

4.两阶段提交无法解决的问题

当协调者出错，同时参与者也出错时，两阶段无法保证事务执行的完整性。
考虑协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。
那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否已经被提交。

举例：假设有一个决策小组由一个主持人负责与多位组员以电话联络方式协调是否通过一个提案，以两阶段提交来说，主持人收到一个提案请求，打电话跟每个组员询问是否通过并统计回复，然后将最后决定打电话通知各组员。要是主持人在跟第一位组员通完电话后失忆，而第一位组员在得知结果并执行后老人痴呆了（有点衰过头了~（´Д`）~），那么即使重新选出主持人，也没人知道最后的提案决定是什么，也许是通过，也许是驳回，不管大家选择哪一种决定，都有可能与第一位组员已执行过的真实决定不一致。

最后别忘了关注我们的微信公众号！谢谢*o*！