从银行转账失败到分布式事务.docxVIP

从银行转账失败到分布式事务 　　提到分布式事务，首先想到的确定是两阶段提交（2pc，?two-phase commit protocol），2pc是格外经典的强全都性、中心化的原子提交协议。中心化是指协议中有两类节点：一个中心化协调者节点（coordinator）和N个参与者节点（participant、cohort）。 　　顾名思义，两阶段提交协议的每一次事务提交分为两个阶段： 　　在第一阶段，协调者询问全部的参与者能否可以提交事务（请参与者投票），全部参与者向协调者投票。 　　在其次阶段，协调者依据全部参与者的投票结果做出能否事务可以全局提交的打算，并通知全部的参与者执行该打算。在一个两阶段提沟通程中，参与者不能转变本人的投票结果。两阶段提交协议的可以全局提交的前提是全部的参与者都同意提交事务，只需有一个参与者投票选择放弃(abort)事务，则事务必需被放弃。? 　　wiki上给出了简要流程： ? ? ?? 　　留意，上图中洗下面一行也表明，两阶段提交协议也依靠与日志，只需存储介质不出问题，两阶段协议就能最终达到全都的形态（成功或者回滚） 　　而下图（来自slideshare）具体描述了整个流程： 　　在刘杰的《分布式原理引见中》，有格外具体的流程引见，可以协作上图一起看，另外还引见了在各种特别情况下（比如Coordinator、Participant宕机，网络分割导致的超时）两阶段协议的工作情况。另外，在这篇文章中也有比较清楚的流程引见。在这里只争辩2PC的优缺点： 　　优点：强全都性，只需节点或者网络最终恢复正常，协议就能保证顺当结束；部分关系型数据库（Oracle）、框架直接支持 　　缺点：两阶段提交协议的容错力量较差，比如在节点宕机或者超时的情况下，无法确定流程的形态，只能不断重试；两阶段提交协议的功能较差， 消息交互多，且受最慢节点影响 　　为什么两阶段提交协议在分布式系统中不适用： 　　系统“水平”伸缩的死敌。基于两阶段提交的分布式事务在提交事务时需要在多个节点之间进行协调,最大限度地推后了提交事务的时间点，客观上延长了事务的执行时间，这会导致事务在访问共享资源时发生冲突和死锁的概率增高，随着数据库节点的增多，这种趋势会越来越严峻，从而成为系统在数据库层面上水平伸缩的枷锁， 这是很多Sharding系统不接受分布式事务的次要缘由。 　　 3PC 　　三阶段提交协议（3pc?Three-phase_commit_protocol）次要是为了处理两阶段提交协议的堵塞问题，从原来的两个阶段扩展为三个阶段，并且添加了超时机制。 　　 　　3PC只是处理了在特别情况下2PC的堵塞问题，但导致一次提交要传递6条消息，延时很大。 TCC ?　　TCC是Try、Commit、Cancel的缩写，在国内由于领取宝的布道而广为人知，TCC在保证强全都性的同时，最大限度提高系统的可伸缩性与可用性。 　　我们假设一个完整的为业务包含一组子业务，Try操作完成全部的子业务检查，预留必要的业务资源，实现与其他事务的隔离；Confirm使用Try阶段预留的业务资源真正执行业务，而且Confirm操作满足幂等性，以遍支持重试；Cancel操作释放Try阶段预留的业务资源，同样也满足幂等性。“一次完整的买卖由一系列微买卖的Try 操作组成，假如全部的Try 操作都成功，最终由微买卖框架来统一Confirm，否则统一Cancel，从而实现了类似经典两阶段提交协议（2PC）的强全都性。” 　　与2PC协议比较 ，TCC拥有以下特点： 　　位于业务服务层而非资源层 ，由业务层保证原子性 　　没有单独的预备(Prepare)阶段，降低了提交协议的成本 　　Try操作 兼备资源操作与预备力量? 　　Try操作可以机警选择业务资源的锁定粒度，而不是锁住整个资源，提高了并发度 　　当然，TCC需要较的高开发成本，每个子业务都需要有响应的comfirm、Cancel操作，即实现相应的补偿规律。 基于消息的分布式事务 ?　　这类事务机制将分布式事务分成多个本地事务，这里称之为主事务与从事务。首先主事务本地先行提交，然后通过消息通知从事务，从事务从消息中猎取信息进行本地提交。可以看出这是一种异步事务机制、只能保证最终全都性；但可用性情外高，不会由于毛病而发生堵塞。另外，主事务已经先行提交，假如由于从事务无法提交，要回滚主事务还是比较麻烦，所以这种模式只适用于理论上或许率等成功的业务情况，即从事务的提交失败可能是由于毛病，而不大可能是规律错误。 　　基于异步消息的事务机制次要有两种方式：本地消息表与事务消息。二者的区分在于：怎样保证主事务的提交与消息发送这两个操作的原子性。 　　假如用异步消息实现转账的例子，那么操作分为四部：用户A扣钱，发消息，用户B收消息，用户B