微服务分布式事物之Seata

事物是什么

概念

事务

指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。

通俗一点？举个生活中的例子：你去小卖铺买东西，“一手交钱，一手交货”就是一个事务的例子，交钱和交货必 须全部成功，事务才算成功，任一个活动失败，事务将撤销所有已成功的活动。

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

事物的四大特性 

原子性（Atomicity）：

操作这些指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回到执行指令前的数据状态。要么执行，要么不执行

一致性（Consistency）：

事务的执行使数据从一个状态转换为另一个状态，数据库的完整性约束没有被破坏。能量守恒，总量不变
 

隔离性（Isolation）：

隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。信息彼此独立，互不干扰

持久性（Durability）：

当事务正确完成后，它对于数据的改变是永久性的。不会轻易丢失

分布式事务
 

随着互联网的快速发展，软件系统由原来的单体应用转变为分布式应用

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

分布式事务产生场景 
 

1.跨JVM进程产生分布式事务
JVM是Java程序运行的环境，每个JVM实例都是独立的进程。跨JVM意味着在不同的进程中运行的Java程序之间进行数据传输、方法调用或其他形式的交互。

典型的场景就是微服务架构 微服务之间通过远程调用完成事务操作。 比如：订单微服务和库存微服务，下单的 同时订单微服务请求库存微服务减库存。

2.跨数据库实例

单体系统访问多个数据库实例 当单体系统需要访问多个数据库(实例)时就会产生分布式事务。比如: 用户信 息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信 息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。

我们了解到了分布式事务的基础概念。与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法 提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持，接下来，我们先来学习一下分布式事务的CAP理论。

CAP原则

CAP原则又叫CAP定理，同时又被称作布鲁尔定理（Brewer's theorem），指的是在一个分布式系统中，不可能同时满足以下三点。

一致性（Consistency）：

指强一致性，在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果。

也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据一致性保证了不管向哪台服务器写入数据，其他的服务器能实时同步数据

可用性（Availability：

可用性是指，每次向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据）
"未崩溃"意味着它仍在正常工作，能够响应请求并执行其功能。

什么是分区

在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域。这就是分区

分区容忍性 (Partition tolerance)：

分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，也就是说，服务器A和B发送给对方的任何消息都是可以放弃的，也就是说A和B可能因
为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。除非整个网络环境都发生了故障

容许节点 G1/G2 间传递消息的差错 (延迟或丢失)，而不影响系统继续运行。
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须
就当前操作在C和A之间做出选择。

为什么只能在A和C之间做出取舍?
分布式系统中，必须满足 CAP 中的 P，此时只能在 C/A 之间作出取舍整个系统由两个节点配合组成，之间通过网络通信，当节点 A进行更新数据库操作的时候，需要同时更新节点 B 的数据库 (这是一个原子的操作)。下面这个系统怎么满足 CAP 呢?我们用反证法 假设可以同时满足一致性、可用性、分区容错这三个特性，由于满足分区容错，可以切断 A/B 的连线，如下图:

可见，根本完成不了，只要出现了网络分区，A就无法满足，因为节点 A根本连接不上节点 B。如果强行满足C 原子性，就必须停止服务运行，从而放弃可用性 C。
若要保证一致性:则必须进行节点间数据同步，同步期间数据锁定，导致期间的读取失败或超时，破坏了可用性:若要保证可用性: 则不允许节点间同步期间锁定，这又破坏了一致性。

所以，最多满足两个条件：

如何权衡保c还是保A?
取舍
        舍弃P(选择C/A): 单点的传统关系型数据库 DBMS(MySQL/Oracle)，但如果采用集群就必须考虑P了
        舍弃A(选择C/P): 是分布式系统要保证P，而且保证一致性，如 MongoDB / HBase;
        舍弃C(选择A/P): 是分布式系统要保证P，而且保证可用性，如 CoachDB / Cassandra / DynamoDB。

        注：redis-cluster是AP，zookeeper写入强一致，读取是顺序一致性(即弱一致)。

对于一个分布式系统来说，CAP三者中
        P是基本要求，只能通过基础设施提升，无法通过降低 C/A 来提升;
        然后在 C/A 两者之间权衡。
一个还不错的策略是:保证可用性和分区容错，舍弃强一致性，但保证最终一致性，比如一些高并发的站点(秒杀、淘
宝、12306) 。最终近似于兼顾了三个特性。