Java 后端程序员必备：分布式事务基础篇

前言

事务是数据库系统中非常有趣也非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全部执行；在 SOA 与微服务架构大行其道的今天，在分布式的多个服务中保证业务的一致性就需要我们实现分布式事务。

数据库事务

数据库事务（简称：事务），是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。

数据库事务的几个典型特性：原子性(Atomicity )、一致性( Consistency )、隔离性( Isolation)和持久性(Durabilily)，简称就是ACID。

• 原子性： 事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
• 一致性： 指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
• 隔离性： 多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。简言之，就是事务之间是进水不犯河水的。
• 持久性： 表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。

分布式事务

分布式事务： 就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。

扫描二维码关注公众号，回复： 11941209 查看本文章

为什么需要分布式事务？接下来分两方面阐述：

微服务架构下的分布式事务

随着互联网的快速发展，轻盈且功能划分明确的微服务，登上了历史舞台。比如，一个用户下订单，购买直播礼物的服务，被拆分成三个service，分别是金币服务（coinService），下订单服务（orderService）、礼物服务（giftService）。这些服务都部署在不同的机器上（节点），对应的数据库（金币数据库、订单数据库、礼物数据库）也在不同节点上。

用户下单购买礼物，礼物数据库、金币数据库、订单数据库在不同节点上，用本地事务是不可以的，那么如何保证不同数据库（节点）上的数据一致性呢？这就需要分布式事务啦~

分库分表下的分布式事务

随着业务的发展，数据库的数据日益庞大，超过千万级别的数据，我们就需要对它分库分表（以前公司是用mycat分库分表，后来用sharding-jdbc）。一分库，数据又分布在不同节点上啦，比如有的在深圳机房，有的在北京机房~你再想用本地事务去保证，已经无动于衷啦~还是需要分布式事务啦。

比如A转10块给B，A的账户数据是在北京机房，B的账户数据是在深圳机房。流程如下：

CAP 理论&BASE 理论

学习分布式事务，当然需要了解 CAP 理论和BASE 理论。

CAP理论

CAP理论作为分布式系统的基础理论，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），这三个要素最多只能同时实现两点。

一致性(C：Consistency)：

一致性是指数据在多个副本之间能否保持一致的特性。例如一个数据在某个分区节点更新之后，在其他分区节点读出来的数据也是更新之后的数据。

可用性(A：Availability)：

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。

分区容错性（P:Partition tolerance）:

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。

选择 说明 CA 放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择 AP 放弃一致性，分区容错性和可用性，这是很多分布式系统设计时的选择 CP 放弃可用性，追求一致性和分区容错性，网络问题会直接让整个系统不可用

BASE 理论

BASE 理论， 是对CAP中AP的一个扩展，对于我们的业务系统，我们考虑牺牲一致性来换取系统的可用性和分区容错性。BASE是Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写。

Basically Available

基本可用：通过支持局部故障而不是系统全局故障来实现的。如将用户分区在 5 个数据库服务器上，一个用户数据库的故障只影响这台特定主机那 20% 的用户，其他用户不受影响。

Soft State

软状态，状态可以有一段时间不同步

Eventually Consistent

最终一致，最终数据是一致的就可以了，而不是时时保持强一致。

本地消息表

ebay最初提出本地消息表这个方案，来解决分布式事务问题。业界目前使用这种方案是比较多的，它的核心思想就是将分布式事务拆分成本地事务进行处理。可以看一下基本的实现流程图：

基本实现思路

发送消息方：

• 需要有一个消息表，记录着消息状态相关信息。
• 业务数据和消息表在同一个数据库，即要保证它俩在同一个本地事务。
• 在本地事务中处理完业务数据和写消息表操作后，通过写消息到MQ消息队列。
• 消息会发到消息消费方，如果发送失败，即进行重试。

消息消费方：

• 处理消息队列中的消息，完成自己的业务逻辑。
• 此时如果本地事务处理成功，则表明已经处理成功了。
• 如果本地事务处理失败，那么就会重试执行。
• 如果是业务上面的失败，给消息生产方发送一个业务补偿消息，通知进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

优点&缺点：

该方案的优点是很好地解决了分布式事务问题，实现了最终一致性。缺点是消息表会耦合到业务系统中。