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

微服务–分布式事务概念澄清事务补偿机制: 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务.CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统.幂等性: 简单的说,?业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID.BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准.柔性事务 vs. 刚性事务刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务.柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型.通常对本地事务采用刚性事务, 分布式事务使用柔性事务.最佳实践先上结论, 再分别介绍分布式事务的各种实现方式.如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中, 也就是尽量使用本地事务, 避免使用强一致性的分布式事务.如果业务场景能够接受最终一致性, 那么最好是使用基于消息的最终一致性的方案(异步确保型)来解决.如果业务场景需要强一致性, 并且只能够进行分布式服务部署, 那么最好是使用TCC方案而不是2PC方案来解决.注意: 以下每种方案都有不同的适用场合, 需要根据实际业务场景来选择.两阶段提交(2PC)两阶段提交(Two Phase Commit, 2PC), 具有强一致性, 是CP系统的一种典型实现.两阶段提交, 常见的标准是XA, JTA等. 例如Oracle的数据库支持XA.示意图图的上半是两阶段提交成功的演示, 下半是两阶段提交失败的演示. 关于两阶段提交网上有很多经典的讲解, 这里就不细说了, 可以参考前面的链接.缺点两阶段提交中的第二阶段, 协调者需要等待所有参与者发出yes请求, 或者一个参与者发出no请求后, 才能执行提交或者中断操作. 这会造成长时间同时锁住多个资源, 造成性能瓶颈, 如果参与者有一个耗时长的操作, 性能损耗会更明显.实现复杂, 不利于系统的扩展, 不推荐.TCC (Try-Confirm-Cancle)TCC, 是基于补偿型事务的AP系统的一种实现, 具有最终一致性.下面以客户购买商品时的付款操作为例进行讲解:Try:?完成所有的业务检查(一致性),预留必须业务资源(准隔离性);?体现在本例中, 就是确认客户账户余额足够支付(一致性), 锁住客户账户, 商户账户(准隔离性).Confirm:?使用Try阶段预留的业务资源执行业务(业务操作必须是幂等的), 如果执行出现异常, 要进行重试.?在这里就是执行客户账户扣款, 商户账户入账操作.Cancle:?释放Try阶段预留的业务资源, 在这里就是释放客户账户和商户账户的锁;?如果任一子业务在Confirm阶段有操作无法执行成功, 会造成对业务活动管理器的响应超时, 此时要对其他业务执行补偿性事务. 如果补偿操作执行也出现异常, 必须进行重试, 若实在无法执行成功, 则事务管理器必须能够感知到失败的操作, 进行log(用于事后人工进行补偿性事务操作或者交由中间件接管在之后进行补偿性事务操作).优点对比与前面提到的两阶段提交法, 有两大优势:TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放,?例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可.TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行.注意事项事务管理器(协调器)这个节点必须以带同步复制语义的高可用集群(HAC)方式部署.事务管理器(协调器)还需要使用多数派算法来避免集群发生脑裂问题.适用场景严格一致性执行时间短实时性要求高举例: 红包, 收付款业务.异步确保型通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响.这个方案真正实现了两个服务的解耦, 解耦的关键就是异步消息和补偿性事务.这里以一个例子作为讲解:执行步骤如下:MQ发送方发送远程事务消息到MQ Server;MQ Server给予响应, 表明事务消息已成功到达MQ Server.MQ发送方Commit本地事务.若本地事务Commit成功, 则通知MQ Server允许对应事务消息被消费; 若本地事务失败, 则通知