分布式事务

什么是事务:

事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。

本地事务:

​在本地事务中大多是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，因此叫数据库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务。

数据库事务的四大特性：ACID

A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况。

C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转 100 元，转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出 100 元，李四账户没有增加 100 元这就出现了数 据错误，就没有达到一致性。

I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务的运行过程的中间状态。通过配置事务隔离级别可以比避免脏读、重复读问题。

D（Durability）：持久性，事务完成之后，该事务对数据的更改会持久到数据库，且不会被回滚。

数据库事务在实现时会将一次事务的所有操作全部纳入到一个不可分割的执行单元，该执行单元的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚。 

分布式事务:

 分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。

分布式理论:

CAP是分布式的基础定理:

 
        在CAD理论中C代表了数据的一致性,A代表了系统的可用性,P代表了分区容错这三个性质对应了分布式系统的三个指标,而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。这也就说明了只存在CA、CP和AP三种模型. C是一致性: 对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。

        A是可用性: 任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给你返回数据，不会给你返回错误，但不保证数据最新，强调只要系统能够使用,返回的结果无论对错都行。

        P是分区容忍性也叫分区容错: 由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

接下来讲讲CAP的权衡问题:由于我们开发的是分布式系统,那就必须涉及到网络交互,而只要是网络交互就一定会有延迟和数据丢失, 这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性，要么保证保证系统不出错。

所以CA模型虽然存在但是我们不需要去考虑.

        接下来讲的就是AP模型, 牺牲系统的强一致性，保证可用性和分区容错性。没有了一致性的束缚，系统中的节点可以将初始值数据响应给每个请求，从而满足可用性的要求。当然实际使用 中系统还是能够提供一定的弱一致性保证。比如分布式系统中，节点使用的本地缓存，可以通过设置有效时间，当有效时间过后，重新加载本地缓存保证了一定的一致性。就像我们去菜市场买菜,拿起一包酸菜,问这个酸菜多少钱,这时候老板回答说是7元,老板娘说是6元,这个就是AP模型,它牺牲了一定的一致性.

        然后CP模型就是牺牲一定的可用性，保证一致性和分区容错性。一个简单的中心式算法能够满足CP要求，一个中心节点维护了数据，其他节点接收到客户端的请求后，自动把请求重定向到中心节点，从中心节点获取到ack后，再把数据响应给客户端。还是说之前的买菜案例, 老板接收到价格询问后，可以询问老板娘酸菜什么价，然后再回复我。此场景中如果老板娘耳背，迟迟不回复老板信息，那么对整体的可用性造成一定影响，所以这是一种CP的选择。

BASE 理论:对CAP的一种补充

1. 强一致性和最终一致性
   CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求 在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
2. Base 理论介绍
   BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。
3. 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。
4. 软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
5. 最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变 为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待.

Seata:

Seata是alibaba的一款开源框架,就是用来处理分布式事务的问题

• Transaction Coordinator（TC）：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各各分支事务的提交或回滚。
• Transaction Manager（TM）： 事务管理器，TM 需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令。
• Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。

他提供了四种处理事务的模式,分别是XA,AT,SAGA和TCC,常用的是AT模式: AT 包含两个阶段

实现步骤是这样的:

首先进行事务代码的时候,会生成一个全局事务ID,然后注册分支实物,所有事务参与者执行结束后，一阶段事务提交, Seata 在执行业务SQL前后，会生成beforeImage和afterImage,并把它们保存到undo_log日志文件中,

• 后面会进入二阶段:
• 如果所有事务提交成功，则二阶段的任务就是删除一阶段生成 的undoLog，并释放全局锁
• 如果部分事务参与者提交失败，则需要根据undoLog对已经注册的事务分支进行回滚，并释放全局锁