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

1、微服务分布式事务概念澄清事务补偿机制 : 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务.cap理论 : cap(consistency, availability, partition tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有 cp系统, ap 系统.幂等性 : 简单的说 ,? 业务操作支持重试, 不会产生不利影响 . 常见的实现方式 : 为消息额外增加唯一id.base (basically avaliable, soft state, eventually consistent): 是分布式事务实现的一

2、种理论标准.柔性事务 vs. 刚性事务刚性事务是指严格遵循acid原则的事务 , 例如单机环境下的数据库事务.柔性事务是指遵循base理论的事务 , 通常用在分布式环境中, 常见的实现方式有:两阶段提交 (2pc), tcc 补偿型提交 , 基于消息的异步确保型, 最大努力通知型 .通常对本地事务采用刚性事务, 分布式事务使用柔性事务.最佳实践先上结论 , 再分别介绍分布式事务的各种实现方式.如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中, 也就是尽量使用本地事务 , 避免使用强一致性的分布式事务.如果业务场景能够接受最终一致性, 那么最好是使用基于消息的最终一致性的方案( 异步

3、确保型 ) 来解决 .如果业务场景需要强一致性, 并且只能够进行分布式服务部署, 那么最好是使用tcc方案而不是 2pc方案来解决 .注意 : 以下每种方案都有不同的适用场合, 需要根据实际业务场景来选择.两阶段提交 (2pc)两阶段提交 (two phase commit, 2pc), 具有强一致性 , 是 cp系统的一种典型实现.两阶段提交 , 常见的标准是xa, jta 等. 例如 oracle 的数据库支持xa.示意图图的上半是两阶段提交成功的演示, 下半是两阶段提交失败的演示. 关于 两阶段提交网上有很多经典的讲解, 这里就不细说了 , 可以参考前面的链接.缺点两阶段提交中的第二阶段

4、, 协调者需要等待所有参与者发出yes 请求 , 或者一个参与者发出 no 请求后 , 才能执行提交或者中断操作. 这会造成 长时间同时锁住多个资源 , 造成性能瓶颈 , 如果参与者有一个耗时长的操作, 性能损耗会更明显 .实现复杂 , 不利于系统的扩展, 不推荐 .tcc (try-confirm-cancle)tcc, 是基于补偿型事务的ap系统的一种实现 , 具有最终一致性 .下面以 客户购买商品时的付款操作为例进行讲解 :try:? 完成所有的业务检查(一致性 ), 预留必须业务资源( 准隔离性 );? 体现在本例中 , 就是确认客户账户余额足够支付(一致性 ), 锁住客户账户 , 商

5、户账户(准隔离性 ).confirm:? 使用 try 阶段预留的业务资源执行业务(业务操作必须是幂等的), 如果执行出现异常, 要进行重试 .? 在这里就是执行客户账户扣款, 商户账户入账操作.cancle:? 释放 try 阶段预留的业务资源, 在这里就是释放客户账户和商户账户的锁;? 如果任一子业务在confirm 阶段有操作无法执行成功, 会造成对业务活动管理器的响应超时 , 此时要对其他业务执行补偿性事务. 如果补偿操作执行也出现异常, 必须进行重试 , 若实在无法执行成功, 则事务管理器必须能够感知到失败的操作, 进行 log( 用于事后人工进行补偿性事务操作或者交由中间件接管在之

6、后进行补偿性事务操作 ).优点对比与前面提到的两阶段提交法, 有两大优势 :tcc能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放 , ?例如 , 假设有 ab两个操作 , 假设 a操作耗时短 , 那么 a就能较快的完成自身的try-confirm-cancel流程 , 释放资源 . 无需等待 b操作 . 如果事后出现问题 , 追加执行补偿性事务即可.tcc是绑定在各个子业务上的( 除了 cancle 中的全局回滚操作 ), 也就是各服务之间可以在一定程度上”异步并行”执行.注意事项事务管理器 (协调器 ) 这个节点必须以带同步复制语义的高可用集群(hac)方式部署 .事务管理器 (

7、协调器 ) 还需要使用多数派算法来避免集群发生脑裂问题.适用场景严格一致性执行时间短实时性要求高举例 : 红包 , 收付款业务 .异步确保型通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响.这个方案真正实现了两个服务的解耦, 解耦的关键就是 异步消息 和补偿性事务 .这里以一个例子作为讲解:执行步骤如下 :1. mq 发送方发送远程事务消息到mq server;2. mq server 给予响应 , 表明事务消息已成功到达mq server.3. mq 发送方 commit本地事务 .4. 若本地事务 commit成功 , 则通知 mq serve

8、r 允许对应事务消息被消费; 若本地事务失败 , 则通知 mq server 对应事务消息应被丢弃.5. 若 mq发送方超时未对mq server 作出本地事务执行状态的反馈, 那么需要 mq servfer向 mq 发送方主动回查事务状态, 以决定事务消息是否能被消费.6. 当得知本地事务执行成功时, mq server允许 mq 订阅方消费本条事务消息.需要额外说明的一点, 就是事务消息投递到mq 订阅方后 , 并不一定能够成功执行.需要 mq 订阅方主动给予消费反馈(ack)如果 mq 订阅方执行远程事务成功, 则给予消费成功的ack, 那么 mq server 可以安全将事务消息移除;

9、如果执行失败 , mq server需要对消息重新投递, 直至消费成功 .注意事项消息中间件在系统中扮演一个重要的角色, 所有的事务消息都需要通过它来传达, 所以消息中间件也需要支持 hac 来确保事务消息不丢失.根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复, 不乱序等其它要求 .适用场景执行周期较长实时性要求不高例如 :跨行转账 / 汇款业务 ( 两个服务分别在不同的银行中)退货 / 退款业务财务 , 账单统计业务 (先发送到消息中间件, 然后进行批量记账 )最大努力通知型这是分布式事务中要求最低的一种, 也可以通过消息中间件实现, 与前面异步确保型操作不同的一点是, 在消息由 mq server 投递到消费者之后,? 允许在达到最大重试次