微服务架构分布式事务设计方案.docx

微 服 务- 分 布 式 事 务概念澄清事务补偿机制:在事务链中的任何一个正向事务操作 ,:CAP(Consistency,Availability,PartitionToleranee), 阐述了一个分布式系统的三个主要方面,只能同时择其二进行实现•常见的有CP系统,:简单的说,?业务操作支持重试,:,softstate,eventuallyconsistent): ,,通常用在分布式环境中,常见的实现方式有:两阶段提交(2PC),TCC补偿型提交,基于消息的异步确保型,,,再分别介绍分布式事务的各种实现方式如果业务场景需要强一致性,那么尽量避免将它们放在不同服务中,也就是尽量使用本地事务,避免使用强一致性的分布式事务•如果业务场景能够接受最终一致性,那么最好是使用基于消息的最终一致性的方案(异步确保型)来解决•如果业务场景需要强一致性,并且只能够进行分布式服务部署,:以下每种方案都有不同的适用场合 ,需要根据实际业务场景来选择•两阶段提交(2PC)两阶段提交(mit,2PC), 具有强一致性,,常见的标准是XA,,下半是两阶段提交失败的演示•关于两阶段提交网上有很多经典的讲解,这里就不细说了,可以参考前面的链接•缺点两阶段提交中的第二阶段,协调者需要等待所有参与者发出 yes请求,或者一个参与者发出no请求后,,造成性能瓶颈,如果参与者有一个耗时长的操作,,不利于系统的扩展,(Try-Confirm-Cancle)TCC,是基于补偿型事务的AP系统的一种实现,:Try:?完成所有的业务检查(一致性),预留必须业务资源(准隔离性);?体现在本例中,就是确认客户账户余额足够支付(一致性),锁住客户账户,商户账户(准隔离性).Confirm:?使用Try阶段预留的业务资源执行业务(业务操作必须是幂等的),如果执行出现异常,要进行重试.?在这里就是执行客户账户扣款,商户账户入账操作•Cancle:?释放Try阶段预留的业务资源,在这里就是释放客户账户和商户账户的锁 ;?如果任一子业务在Confirm阶段有操作无法执行成功,会造成对业务活动管理器的响应超时,,必须进行重试,若实在无法执行成功,则事务管理器必须能够感知到失败的操作 ,进行log(用于事后人工进行补偿性事务操作或者交由中间件接管在之后进行补偿性事务操作).优点对比与前面提到的两阶段提交法,有两大优势:TCC能够对分布式事务中的各个资源进行分别锁