微服务架构下分布式事务处理方案选择和对比 _微服务架构

文章插图

作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

在微服务架构下，我们最容易遇到的一个问题就是分布式事务处理问题，当你微服务模块拆分的越细，那么遇到分布式事务处理的场景就越多。即使是同一个微服务模块，对应一个业务数据库，但是你某个业务逻辑的实现是调用两个Service接口服务来完成的，同样也是分布式事务问题。
因此有必要对分布式事务整体解决思路总下总结。
分布式事务概述

文章插图

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
一个分布式事务包含一组操作序列，由两个或两个以上的网络主机参与。通常主机提供事务性资源，而事务管理器负责创建和管理全局事务，由事务管理器协调事务参与的资源。分布式事务和本地事务并无太大不同，也需保证事务的四个属性（原子性、一致性、隔离性、持久性）。
对于分布式事务的潜在场景，可以简单的分为三类：
1.跨资源
一个完整业务需要操作两个独立数据库，比如需要在A数据库插入一条订单记录，同时更新B数据库中的库存状态，两个操作跨数据库，但是需要控制在一个完整事务里面。
2.资源+服务组合
在和工作流集成场景中出现，业务用户在提交单据的时候需要后台执行两个操作，首先是调用本地API将单据数据保存到本地数据库，其次是调用启动流程WebService服务。
3.跨服务
由于Web Service服务本身无状态，即使是同一个数据库提供给处理的两个WebService服务，在进行调用和组合的时候也属于分布式事务控制。
对于分布式事务的主流解决方法，主要包括了XA两阶段提交，事务补偿和基于BASE的最终一致性（可靠消息传输），首先再对这三种方法做下简单描述。
强一致性-两阶段提交模型

文章插图

两阶段提交，因为它是实现XA分布式事务的关键（确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做）。所谓的两个阶段是指：第一阶段：准备阶段和第二阶段：提交阶段。具体过程如下：
阶段一：开始向事务涉及到的全部资源发送提交前信息

此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免于难并且在失败之后可以重新对所有资源进行更新。
阶段二：只在阶段一没有异常结束的时候才会发生

此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。事务管理器将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。
从以上工作过程可以看出，两阶段提交协议正确工作的前提假设是每个节点都会记录写前日志（write-ahead log）并持久性存储，即使节点发生故障日志也不会丢失。同时假设节点不会发生永久性故障而且任意两个节点都可以互相通信。
两阶段提交优缺点分析
两阶段提交协议最大的劣势是其通过阻塞完成的协议，在事务参与者等待消息的时候处于阻塞状态，事务参与者中其他进程则需要等待阻塞进程释放资源才能使用。如果事务管理器发生了故障，那么事务参与者将无法完成事务则一直等待下去。同时两阶段提交协议没有容错机制，一个节点发生故障整个事务都要回滚，代价比较大。
两阶段提交协议仅在一种情况下可能导致数据不一致，所有或部分参与者都响应了Prepare阶段，在任何参与者收到事务管理器提交或回滚决定之前事务管理器宕机死亡，此时所有参与者都必须等待事务管理器恢复。而可能事务管理器此时已经丢失了事务上下文，这时需人工介入参与数据恢复。