zookeeper入门系列 : 分布式事务

上一章我们了解了zookeeper到底是什么,这一章重点来看zookeeper当初到底面临什么问题?而zookeeper又是如何解决这些问题的?

实际上zookeeper主要就是解决分布式环境下的一致性问题。那么解决这个问题到底有哪些难点呢?我们一步一步来阐述和推理这个过程。

分布式事务

我们首先考虑一致性的特殊情况,即分布式事务的情况。分布式事务对于一致性的要求是强一致性,因此对于我们后续讨论有一定的借鉴意义。这里我们用到一个经典的例子:bob给smith转账,强一致性的要求一定是需要对外来说bob减钱的同时smith加钱。见文献1(图片也来源于文献1)

单机环境下是这样的

zookeeper入门系列 : 分布式事务

简单讲就是有关bob的减钱和smith的加钱都转同一个库来做,可以采用数据库的事务特性轻松支持。保证bob给smith转账的安全性。

而分布式环境就变这样了

zookeeper入门系列 : 分布式事务

假设应用服务器是A,bob端的数据库是B,smith端的数据是C,那么A做成一个转账,需要B事务成功提交,并且C事务成功提交。然而因为网络的影响,可能出现两种情况

1. 如果bob扣款成功,而网络通知smith失败了,则会出现bob的钱减了,smith的钱没加

2. 如果bob扣款不成功,而smith加钱成功了,则会出现smith钱增加了,但是bob的钱也没减少

2PC

这种不一致的问题困扰着大家。任意一边出错想要回滚另一边都不是简单的数据库回滚的事情( 因为此时已经成功提交),而是需要做业务的逆向操作,而不同业务的逆操作都不同,导致复杂性增加。考虑数据库事务的执行实际上是先将执行操作写入binlog,等到最后通过一个commit指令将binlog的内容一次更新到表中,或者写到一半通过一个rollback指令将binlog中的内容回滚。于是乎,可以想到使用2个阶段来执行这个过程,第一阶段,写入binlog;第二阶段执行commit或者rollback。这就是著名的两阶段提交协议(2PC)。如果仔细考虑,会发现两阶段协议并没有解决问题,只不过降低了出错的概率而已,因为第二阶段同样存在上面的两种情况。注意最终状态是多台机器的状态&&的 结果。以下是两阶段协议的时序图:

zookeeper入门系列 : 分布式事务

1. 考虑prepare阶段的响应(因为请求阶段和执行阶段都可以在最后响应中体现出来),对于分布式环境中,任意时刻考虑3种状态:成功、失败、超时。

a.成功。不必处理,执行后续行为commit。

b.失败。这是执行阶段出错,执行后续行为rollback。

c.超时。这可能是执行阶段太慢,也可能是网络阶段太慢或丢包,但是保守处理,超时可以当做出错。

可以看出,prepare阶段的问题能够完全避免。

2. 考虑commit阶段,同样考虑成功失败超时3种状态。

a. 成功。整个事务成功执行

b. 失败。提交出错,假设此时前面的B已经提交成功了,则同样面临需要回滚B却无法回滚的问题,因为B已经提交成功了。

c. 超时。同上。

还有一种例外情况,即prepare阶段完成后A挂了,则B,C即进入不知所措的状态。

可以看出,在2PC中事务无法做到像单机一样安全,只不过降低了出问题的概率。

3PC

针对如何解决2PC中的例外情况,出现了3阶段提交协议。3阶段的主要改进是把2阶段的prepare再分为canCommit和preCommit两个阶段。 

1. 考虑cancommit阶段的响应。

a.成功。不必处理,执行后续行为precommit。

b.失败。说明无法执行,无须后续提交或回滚行为。

c.超时。保守处理,超时可以当做失败。

2. 考虑precommit阶段的响应。

a.成功。不必处理,执行后续行为docommit。

b.失败。执行阶段出错,执行后续行为rollback。

c.超时。执行阶段太慢,也可能是网络阶段太慢或丢包,但是保守处理,超时可以当做出错。

3. 考虑cancommit阶段的响应。

a.成功。整个事务成功执行。

b.失败。提交出错,假设此时前面的B已经提交成功了,则同样面临无法回滚的问题。

c.超时。保守处理,超时可以当做失败。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyyyss.html