从银行转账失败到分布式事务：总结与思考

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！

正文

大年夜银行转账掉败到分布式事务：总结与思虑

关系型数据库事务

大年夜多半人可能和我一样，第一次据说事务是在进修关系型数据库(mysql、sql server、Oracle)的时刻，在关系型数据库中，如不雅一组操作知足ACID特点，那么称之为一个事务。关于关系型数据库的ACID特点，不管是教材┞氛样收集上都有大年夜量的材料，这里只简单介绍。

A(Atomic)：原子性，构成事务的所有操作，要么都履行完成，要么全部不履行，弗成能出现部分成功部分掉败的情况
C(Consistency)：一致性，在事务履行前后，数据库的一致性束缚没有被破坏。这里的一致性含义后面会具体解释
I(Isolation)：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的履行互不干扰，一个事务不克不及看到其他事务运行过程的中心状况
D(Durability)：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚。

我们举一个简单的转账的例子，用户A给玩家B转100块钱，那么涉及到两个操作：玩家A的┞匪户扣100元，玩家B的┞匪户加100元。即

UserA.account -= 100  
UserB.account += 100

原子性很好懂得，这两个操作要么都成功，要么都不履行(更精确的是大年夜效不雅上来看等价于都没有履行)。弗成能出现用户A的钱削减了而用户B的钱没增长的情况，用户是不许可的;更弗成能出现用户B的钱增长而用户A的钱没有削减的情况，银行是绝对不干的。

一致性说一路来大年夜家都懂，然则深究起来也是似懂非懂。ACID中的一致性，收集上的介绍都很模糊，都是说要处于一致的状况，那什么是一致的状况呢，比如转账操作中，A扣钱，B加钱，AB的钱的综合是必定的，这个是否属于ACID中的Consistency呢?我认为不是的，Wiki Transaction_processing和Wiki： ACID分别是这么描述的

Consistency: A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state.
The consistency property ensures that any transaction will bring the database from>
READ_UNCOMMITTED
READ_COMMITTED
REPEATABLE_READ
SERIALIZABLE

来解决事务并发中带来的一下几个问题脏读(Dirty Read)、弗成反复读(Non-repeatable Read)、幻读(Phantom Read)

不合的数据库或者说存储引擎默认支撑不合的隔离级别，比如InnoDB存储引擎默认支撑REPEATABLE_READ，而Mongodb只支撑READ_UNCOMMITTED

持久性须要推敲到一个事务在履行过程中的各类情况的异常。一个事务的流程是如许的：

开启一个事务
履行一组操作
如不雅都履行成功，那么提交并停止事务
如不雅任何操作掉败，那么回滚已经履行的操作，停止事务
在事务履行过程中，如不雅出现故障，比如断电、宕机，这个时刻就要应用日记(redo log或者undo log) 加上 checkpoint来包管事务的完全停止。

分布式事务

3PC只是解决了在异常情况下2PC的壅塞问题，但导致一次提交要传递6条消息，延时很大年夜。具体流程描述可拜见《关于分布式事务、两阶段提交协定、三阶提交协定》一文。

事务是一个异常广义的词汇，各行各业解读都不一样。对于法度榜样员，事务等价于Transaction，是指一组持续的操作，这些操作组合成一个逻辑的、完全的操作。即这组操作履行前后，体系须要处于一个可预知的、一致的状况。是以，这一组操作要么都成功履行，要么都不克不及履行;如不雅部分成功，部分掉败，成功的部分须要回滚(rollback)。

当数据的范围越来越大年夜，超出了单个关系型数据库的处理才能，这个时刻就出现了关系型数据的垂直分表或者分表，也出现了天然支撑程度扩大(sharding)的NoSql。别的，大年夜型网站的办事化(SOA)以及这两年异常火的微办事，往往将办事进行拆分，零丁安排，天然也应用自力的数据库，甚至是异构的数据库。这个时刻，关系型数据库包管事务的手段，比如加锁、日记就行不通了。当然，本文评论辩论的不仅仅是数据库，也包含分布式存储、消息队列，以及任何要包管原子性、持久性的逻辑。

分布式事务的最大年夜挑衅在于CAP，在《CAP理论与MongoDB一致性、可用性的一些思虑》一文中有具体介绍。简而言之，因为收集瓜分(P： Network Partition)的存在，用户不得不在一致性(C Consistency)与可用性(A： Avaliable)之前做衡量。如不雅要包管强一致性(主如果应用层面的强一致性)，那么在收集瓜分的时刻，体系就弗采取;如不雅要包管高可用性，那么就只能供给弱一致性，包管最终一致。下面提到的各类实现分布式事务的办法、协定都须要在一致性与可用性之间衡量。

2PC

提到分布式事务，起首想到的肯定是两阶段提交(2pc， two-phase commit protocol)，2pc是异常经典的强一致性、中间化的原子提交协定。中间化是指协定中有两类节点：一个中间化调和者节点(coordinator)和N个介入者节点(participant、cohort)。

1/4 1 2 3 4 下一页尾页

　　推荐阅读

　　基于Zookeeper的分布式锁

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！这篇文┞仿只须要你10分钟的时光。什么是Zookeeper?固然zookeeper的实现比较复杂，然则它供给的模型抽象倒是>>>详细阅读

本文标题：从银行转账失败到分布式事务：总结与思考

地址：http://www.17bianji.com/lsqh/38129.html

1/2 1