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

微服务 分布式事务 概念澄清 事务补偿机制事务补偿机制 在事务链中的任何一个正向事务操作 都必须存在一个完全符合回 滚规则的可逆事务 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 方式部署 事务管理器 协调器 还需要使用多数派算法来避免集群发生脑裂问题 适用场景 严格一致性 执行时间短 实时性要求高 举例 红包 收付款业务 异步确保型 通过将一系列同步的事务操作变为基于消息执行的异步操作基于消息执行的异步操作 避免了分布式事务中 的同步阻塞操作的影响 这个方案真正实现了两个服务的解耦 解耦的关键就是异步消息异步消息和补偿性事务 这里以一个例子作为讲解 执行步骤如下 1 MQ 发送方发送远程事务消息到 MQ Server 2 MQ Server 给予响应 表明事务消息已成功到达 MQ Server 3 MQ 发送方 Commit 本地事务 4 若本地事务 Commit 成功 则通知 MQ Server 允许对应事务消息被消费 若本地事 务失败 则通知 MQ Server 对应事务消息应被丢弃 5 若 MQ 发送方超时未对 MQ Server 作出本地事务执行状态的反馈 那么需要 MQ Servfer 向 MQ 发送方主动回查事务状态 以决定事务消息是否能被消费 6 当得知本地事务执行成功时 MQ Server 允许 MQ 订阅方消费本条事务消息 需要额外说明的一点 就是事务消息投递到 MQ 订阅方后 并不一定能够成功 执行 需要 MQ 订阅方主动给予消费反馈 ack 如果 MQ 订阅方执行远程事务成功 则给予消费成功的 ack 那么 MQ Server 可以 安全将事务消息移除 如果执行失败 MQ Server 需要对消息重新投递 直至消费成功 注意事项 消息中间件在系统中扮演一个重要的角色 所有的事务消息都需要通过它来传达 所以消息中间件也需要支持 HAC 来确保事务消息不丢失 根据业务逻辑的具体实现不同 还可能需要对消息中间件增加消息不重复 不乱序 等其它要求 适用场景 执行周期较长 实时性要求不高 例如 跨行转账 汇款业务 两个服务分别在不同的银行中 退货 退款业务 财务 账单统计业务 先发送到消息中间件 然后进行批量记账 最大努力通知型 这是分布式事务中要求最低的一种 也可以通过消息中间件实现 与前面异步确 保型操作不同的一点是 在消息由 MQ Server 投递到消费者之后 允许在达到允许在达到 最大重试次数之后正常结束事务最大重试次