什么是分布式事务？
介绍这个之前，先来了解一下这几个问题
- 什么是事务？
- 什么是本地事务？
- 什么是分布式？
- 什么是分布式事务？
什么是事务？
完成某件事情，需要执行多个步骤，最终多个步骤要么全部成功，要么全部失败。这个过程中可能有多个参与者。
举个例子：微信上A给B转账100元，A账户减少100，B账户增加100，这就是一个事务，这个操作中要么都成功，要么都失败。
事务的场景有很多，参与者也是多种多样
- 用户注册成功发送邮件，包含2个操作：db中插入用户信息，给用户发送邮件，主要的2个参与者：db、邮件服务器
- 使用支付宝充值话费，包含2个操作：支付宝账户资金减少，手机余额增加，主要的2个参与者：支付宝账户、手机号服务商账户
事务的参与者是多种多样的，不过本文我们主要以db中的事务来做说明。
什么是本地事务？
本地事务，通俗点理解：即事务中所有操作发生在同一个数据库中的情况。
本地事务是在单个数据源上进行数据的访问和更新，而分布式事务是跨越多个数据源来进行数据的访问和更新。
比如A给B转账，A和B的账户位于同一个数据库中。
通常我们用的都是关系型数据库，比如：MySQL、Oracle、SQL Server，这些数据库默认情况，这些db已经实现了事务的功能，即在一个db中执行一个事务操作，db本身就可以确保这个事务的正确性，而不需要我们自己去考虑如何确保事务的正确性。本地事务依赖于数据库事务。mysql实现分布式事务需要基于XA。
开启事务的目的是为了确保数据的准确性，如果需要同时执行多条SQL语句，则需要放到事务中进行，只要其中有一行执行失败，则事务回滚。如果只是查询操作，不牵扯对数据库内容的更改，一般不需要开启事务。事务的初衷是可以回到最近一次的状态。多次查询的情况没有加事务的必要，因为可能涉及的也只是数据一致性问题，而数据一致性问题可以设置事务隔离级别解决。另外，没有必要的事务尽量不用，影响性能。
数据库事务的4大特性
一致性(Consistency)
事务操作之后的结果和期望的结果是一致的，A给B转账100，事务结束之后，看到A的账户应该减少100，B的账户应该增加100，不会出现其他情况
原子性(Atomicity)
事务的整个过程如原子操作一样，最终要么全部成功，或者全部失败，这个原子性是从最终结果来看的，从最终结果来看整个过程是不可分割的。
隔离性(Isolation)
一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性(Durability)
一个事务一旦提交，他对数据库中数据的改变就应该是永久性的。当事务提交之后，数据会持久化到硬盘，修改是永久性的。
什么是分布式？
完成某件事情有多个参与者，多个参与者分布在不同的机器中，这些机器之间通过网络或者其他方式进行通讯。
比如使用工行卡给支付宝充值，工行卡的账户位于工商银行的db中，而支付宝账户位于支付宝的db中，2个db位于不同的地方。
什么是分布式事务？
分布式、事务这2个概念大家都理解了，那么分布式事务很容易理解了：事务的多个参与者分布在不同的地方。
单个db中我们很容易确保事务的正确性，但是当事务的参与者位于多个db中的时候，如何确保事务的正确性呢？
比如：A给B转账，A位于DB1中，B位于DB2中
step1.通过网络，给DB1发送指令：给A账户减少100
step2.通过网络，给DB2发送指令：给B账户增加100
step1成功之后，执行step2的时候，网络出现故障，导致step2执行失败，最终：A减少了100，B却没有增加100，最终的结果和期望的结果不一致，导致了事务的失败。
在介绍分布式事务的解决方案之前，我们需要先了解另外2个概念：CAP和Base理论，这2个理论为分布式事务的解决提供了依据。
分布式事务产生的场景
- 跨数据库实例产生分布式事务
- 跨网络远程调用产生分布式事务
- 跨数据库实例+网络远程调用产生分布式事务
CAP原则
理解CAP概念
CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。分布式系统中，至多满足其中两者。
下边我们分别来解释：
为了方便对CAP理论的理解，我们结合电商系统中的一些业务场景来理解CAP。
如下图，是商品信息管理的执行流程：
整体执行流程如下：
1、商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）
2、主数据库向商品服务响应写入成功。
3、商品服务请求从数据库读取商品信息。
C – Consistency
一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态，即一致的。
上图中，商品信息的读写要满足一致性就是要实现如下目标：
1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。
2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。
如何实现一致性？
1、写入主数据库后要将数据同步到从数据库。
2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入从库的过程中，客户端向从数据库查询到旧的数据。
分布式系统一致性的特点：
1、由于存在数据同步的过程，写操作的响应会有一定的延迟。因为一旦写入主数据库成功，就会开始响应和同步的工作，所以响应稍有延迟，但延迟在可以接受的范围内。
2、为了保证数据一致性，会对资源进行暂时性锁定，待数据同步完成后释放锁定资源。
3、如果请求到数据同步失败的节点将会返回错误信息，一定不会返回旧数据。
A – Availability
可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。
上图中，商品信息读取满足可用性就是要实现如下目标：
1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。
2、从数据库不允许出现响应超时或响应错误。
如何实现可用性？
1、写入主数据库后要将数据同步到从数据库。
2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
3、即使数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。
分布式系统可用性的特点：
1、 所有请求都有响应，且不会出现响应超时或响应错误。
P – Partition tolerance
通常分布式系统的各个节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致节点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。
上图中，商品信息读写满足分区容忍性就是要实现如下目标：
1、主数据库向从数据库同步数据失败不影响读写操作。
2、其一个节点挂掉不影响另一个节点对外提供服务。
如何实现分区容忍性？
1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样节点之间能有效的实现松耦合。
2、添加从数据库节点，其中一个从结点挂掉其它从节点继续提供服务。(从数据库可以多个，即多个从数据库节点)
分布式分区容忍性的特点：
1、分区容忍性分是布式系统具备的基本能力
CAP组合方式
1、上边商品管理的例子是否同时具备 CAP呢？
在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的。
如果不要求P，则C（强一致性）和A（可用性）是可以保证的。CA系统基本上是单机系统，比如单机数据库。
比如：
下图满足了P即表示实现分区容忍：
本图分区容忍的含义是：
1）主数据库通过网络向从数据同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。
2）当主数据库和从数据库之间的网络出现问题，不影响主数据库和从数据库对外提供服务。
3）其一个节点挂掉不影响另一个节点对外提供服务。
如果要实现C则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据(未同步更新的旧数据)则需要将从数据库数据锁定，待同步完成后解锁，如果同步失败，从数据库要返回错误信息或超时信息。
如果要实现A则必须保证数据可用性，不管任何时候都可以向从数据查询数据，且不会响应超时或返回错误信息，此时不能锁定从数据库。
通过分析发现在满足P的前提下C和A存在矛盾性，如下：
主从库之间网络出现故障的情况下，主库的数据无法同步给从库，为了确保外面看到数据是一致的，此时从库不能让外部访问，只能让主库对外提供服务，从库失去了可用性。
主从库之间网络出现故障的情况下，主库的数据无法同步给从库，此时2个库数据是不一致的，如果此时允许2个库都可以对外提供服务（可用性），那么2个库访问的数据是不一致的。
所以CAP无法同时满足，通常情况下，在分布式系统中，多个节点分布在不同的网络节点中，网络故障是无法完全避免的。所以P是肯定会存在的，此时我们需要考虑P和另外2个(C/A)如何组合的问题。
2、CAP有哪些组合方式呢？
所以在生产中对分布式事务处理时要根据需求来确定满足CAP的哪两个方面。
1）AP：
放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。
例如：
上边的商品管理，完全可以实现AP，前提是只要用户可以接受所查询到的数据在一定时间内不是最新的即可。
通常实现AP都会保证最终一致性(一段时间后做到强一致性)，后面讲的BASE理论就是根据AP来扩展的，一些业务场景 比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受那么在一定时间内到账即可。
2）CP：
放弃可用性，追求一致性和分区容错性，zookeeper其实就是在追求强一致。
3）CA：
放弃分区容忍性，即不进行分区，不考虑由于网络不通或节点挂掉的问题，则可以实现一致性和可用性。一般出现在单机情况。
那么系统将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA。
上边的商品管理，如果要实现CA则架构如下：
主数据库和从数据库中间不再进行数据同步，数据库可以响应每次的查询请求，通过事务隔离级别实现每个查询请求都可以返回最新的数据。
总结
通过上面我们已经学习了CAP理论的相关知识，CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，节点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致性，保证最终一致性。
Base理论
理解强一致性和最终一致性
CAP理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和CAP中的一致性不同，CAP中的一致性要求在任何时间查询每个节点，数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个节点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
Base理论介绍
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用，但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。
基本可用
分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易中付款出现问题了，商品依然可以正常浏览。
软状态
由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的”支付中”、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
最终一致性
最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的”支付中”状态，最终会变为“支付成功”或者”支付失败”，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待 。
本文地址：https://blog.csdn.net/wxd772113786/article/details/107576627