关于分布式事务

Posted 2021-04-25 代老板的鱼塘

微服务架构中，系统被拆分为独立部署和扩展的模块边界，系统间通过服务交互，分布式系统间的数据一致性成为挑战，本文集中对分布式事务进行一下总结。

一致性模型

01

强一致性

当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种事务对用户最友好的，就是用户上一次写什么，下一次就能读到什么，但是这种实现对性能影响较大。

02

弱一致性

系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到，但会尽可能保证在某个时间级别之后，可以让数据达到一致性状态。

03

最终一致性

弱一致性的特定形式，系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和数据副本的个数影响。

事务的理论基础

01

ACID

在传统数据库系统中，事务具有ACID四个属性。

• 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。

• 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致的状态。一致性代表了底层数据存储的完整性。

• 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影像的独立环境执行。

• 持久性（Durable）：事务完成之后，它对数据的修改是永久性的，即使出现系统故障也能够保持。

在金融行业，与可用性和性能相比，一致性是最重要的，用户可以容忍系统故障而停止服务，但决不能容忍账户的钱出现问题，而强一致性事务是根本的保证。

02

CAP

CAP理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• 一致性（Consistency）：一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

• 可用性（Availability）：可用性指“reads and writes always succeed”，即服务一直可用，而且是正常响应时间。

• 分区容错性（Partition tolerance）：分区容错性是指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

根据CAP理论，无法满足一致性、可用性和分区容错性这三个特性，所以需要进行取舍。

牺牲分区（CA模型）

牺牲可用性（CP模型）

牺牲一致性（AP模型）

03

BASE

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（CAP的一致性就是强一致性），但应用可以采用适合的方法达到最终一致性。

BASE是指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。

• 基本可用（Basically Avaliable）：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。对于高并发大流量的场景，可以采用服务降级、限制流量的方式，这就是损失部分可用性的体现。

• 软状态（Soft State）：软状态是指允许系统存在中间，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。

• 最终一致性（Eventual Consistency）：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

分布式事务解决方案

01

两阶段提交型（2PC）

下图为XOpen组织提供的DTP模型图：

XA协议指的是TM（事务管理器）和RM（资源管理器）之间的接口。目前主流的关系型数据库产品都是实现了XA接口的。JTA(Java Transaction API)是符合X/Open DTP模型的，事务管理器和资源管理器之间也使用了XA协议。 本质上也是借助两阶段提交协议来实现分布式事务的。

在JavaEE平台下，WebLogic、Webshare等主流商用的应用服务器提供了JTA的实现和支持。而在Tomcat下是没有实现的，这就需要借助第三方的框架Jotm、Atomikos等来实现，两者均支持spring事务整合。以下为Springboot中Atomikos的实现配置。

这种方式实现难度不算太高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况。但分布式事务对性能的影响会比较大，不适合高并发和高性能要求的场景。

02

事务补偿型

事务补偿型主要包括TCC模式和补偿/冲正模式，与2PC协议相比是位于业务服务层，而非资源层。

03

事件驱动型

事件驱动通常采用两种方式：

方式一：

• 业务活动的主动方在完成业务处理的同一个本地事务中，记录消息数据

• 业务处理事务提交后，通过实时消息服务通知业务被动方，实时通知成功后删除消息数据

• 消息回复系统定期找到未成功发送的消息，交给实时消息服务补发送

方式二：

• 业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送

• 业务处理服务在业务事务提交后，向实时消息服务确认发送，只有在得到确认发送指令后，实时消息服务才真正发送消息

• 消息状态确认系统定期找到未确认发送或回滚发送的消息，项业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效

事件驱动的实现方式主要有两种：

• 存储事件列表，采用定时轮询扫描的方式，去检查事件数据，发送给目的地

• 采用MQ

最后

  以上为本人对分布式事务的一个总结，固然没有涵盖所有的解决方案，但对于分布式事务问题目前仍旧没有“完美”的解决方案，同时对于CAP理论的质疑也一直存在。所以在实际系统建设中，应该根据具体的业务场景，选择最适合的方案。