分布式事务

1 概述

事务是数据库操作的最小执行单元。不可分割。要么全成功要么全失败。
分布式事务就是分布式场景下的不可分割的一组操作。
分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。

2 出现场景及解决方案

1 一种是跨jvm进程之间调用，底层数据库不是同一个。
2 一种是跨jvm进程之间调用，底层数据库是同一个。
3 还有一种情况：单一服务多数据源产生的分布式事务。

如果业务需要强一致性且并发较小，事务较短则可以使用刚性事务。
我这里会用：seata at
如果业务对一致性要求并没有那么的高。只是最终一致即可。且事务较长。要求高并发、高可用则使用柔性事务： 本地消息表、TCC、saga。

1、2 根据业务场景采用。满足刚性事务(acid) 2pc、3pc或者是满足(柔性事务)base理论的事务mq或本地消息表。
或TCC。
3 可以采用spring的全局事务JTA的解决方案Atomikos

分布式事务解决方案：
1 XA
2 2PC:seata AT模式、TCC
3 3PC
4 本地消息表
5 事务mq
这里的解决方案我用过的是 seata xa、seata at、seata TCC、本地消息表。根据自己理解写一下。
xa协议有很多数据库支持。
优点：代码入侵小，很多数据库都支持xa协议。
缺点：阻塞。不同分支的提交，要么全部提交要么全部回滚
seata AT模式：
优点：代码入侵小，本地事务提交，非阻塞。与xa相比是通过逆向解析undo_log中的数据执行前后镜像生成sql来进行数据的回滚。
缺点：响应时间增强。对数据库压力增加。虽然代码入侵小但是一个事务要生成前后镜像。增加了响应时间。
TCC：将2pc手动实现。一个分支事务对应三个方法。try、commit、rollback。
优点：非阻塞。不需要数据库支持XA协议。
缺点：代码入侵性强。增加业务压力。如果是老业务则无法很好兼容改造。
本地消息表：
优点：根据事务执行状态进行补偿或回滚、非阻塞、支持高并发。无锁。使用乐观锁。
缺点：基于base理论。允许出现中间状态。只是最终一致。因为需要重试。所以要求整个执行流程幂等。

3 分布式事务之柔性or刚性

分布式事务实现方案从类型上可以分为：
刚性事务：满足acid，通常无业务改造，代码入侵低，低并发。适合短事务。XA协议（2PC、JTA）、3PC。
柔性事务：有业务改造，最终一致性。高并发，高可用。对一致性要求不高的场景。适合长事务。基于base理论来实现。TCC、Saga、本地事务消息、事务消息。

长事务：处理流程比较长，很长的时间不能结束。
短事务：处理流程短，可以很快结束。

柔性事务针对分布式事务的解决方式：
1 记录日志+补偿：根据记录找到当前状态进行正向或逆向补偿
2 消息：多次重试，内部程序业务要进行幂等操作。
3 无锁设计，（只要加锁就会导致不同程度的阻塞）可以通过乐观锁进行实现。
（其实刚性事务和柔性事务都满足事务的acid，柔性事务，原子性：要么都成功都失败通过补偿机制来实现。
隔离性相当于最低的读未提交。一致性：最终一致。持久性：通过数据库存储来实现。）

4 分布式(提供数据服务)系统基础理论cap

看了很多的博客发现都说cap是分布式系统的基础理论。但是发现这里指的应该是数据分布式系统
或者是提供数据服务的分布式系统。
cap在各个系统的应用：
ca：多是关系型数据库 mysql、postgreSql、greenplum、vertica、neo4J 单点集群。
cp：Hbase、Redis、MonMongoDB、BerkeleyDB、BigTable。zookeeper。nacos
ap：Cassandra、Voldemort、Dynamo、CouchDB、Riak。nacos/eruak。

1 cap的由来:最初的分布式架构没有自己的设计规范。多人开发的时候。不同服务之间的调用采用的解决方式不同。
很有可能一方不停的重试。一方是直接断开，记录状态之后处理。在这种没有规范的情况下，cap才被人提出来。
2 cap定理表达了一个数据分布式系统不能同时满足以下三个特点。
 Consistency:一致性
 Availability：可用性
 Partition tolerance：分区容忍性
所以在讨论cap原理的时候，更多的是针对有数据存储、数据复制的分布式存储系统。

面试的时候可能会有人问这三个做注册中心有什么区别。

注册中心：zookeeper、nacos、euraka
zookeeper：是cp
euraka：是ap 去中心化，因为不能保证一致性所以会出现以下情况：如果服务在15分钟内没有正常心跳：
1: Eureka 不再从注册列表中移除因为长时间没有收到心跳而过期的服务。
2：Eureka 仍然能够接收新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点可用）
3： 当网络稳定后，当前实例新的注册信息会被同步到其它节点中
nacos：满足ap和cp默认是ap若要切换cp则：通过curl调用：
curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

4.1cap理论详解

一致性：这里的一致性指的是写一致：即所有节 点写入数据后都要进行同步。读一致：写入的请求要在读请求中即时可以
读取。
可用性：满足两点：1 在业务允许的时间内返回结果 2 所有可以正常接收请求的节点需要返回结果。
分区容忍性：分布式的存储系统会有很多的节点，这些节点是通过网络进行通信的。网络不可靠的时候通信出现问题
即出现分区。两种情况 
1 可能由于服务器机房内的交换机、路由器等底层网络设备出现了故障导致出现通信问题
2 服务器发生宕机也会导致节点之间通信出现问题。分区容忍即：哪怕服务器出现分区。也要正常提供服务。

也就是说如果p是不可避免的那么在ap和cp中选择的时候。如果容忍了分区。要么满足可用性要么满足一致性。如果
ap：即满足可用性和分区容忍性。如果服务器之间不可通信。也要可以立马返回数据。就不能保证一致性。哪怕服务器发
生宕机。也要返回数据成功或者失败。
cp：满足一致性和分区容忍性。即如果服务器之间不可通信，则等待服务器之间可以通信之后数据进行同步完成之后再
返回结果，期间则可能进行阻塞。如果服务器发生宕机则等待服务器启动之后再返回数据。这种情况无法满足可用性。

CA
放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。
那么系统将不是一个标准的分布式系统，最常用的关系型数据就满足了 CA。

4.2cap理论缺点

1 cap理论没有考虑延迟性。即认为数据的一致性是立即生效的。没有考虑数据保持一致性是需要时间的。
（这就导致会出现中间状态）
2 cap并不严谨。cap定理不能同时满足三个特点。只能三选二单并不是完全放弃剩余没有选择的那一项。即如果是
cp(zookeeper)则并不是完全不可用。可以尽量满足可用性。ap强调可用性时也会采取相应手段保证数据最终一致。

由于cap理论的一致性是无法立即生效的所以会有很多架构选择ap而保证数据的最终一致性。以此延伸出了base理论

4 分布式(提供数据服务)系统基础理论base

base理论：base理论是对cap中一致性和可用性权衡的结果。针对cap理论的不足进行的延伸和补充：
即使无法达到强一致性，但是每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
1 软状态  由于cap中的一致性并没有考虑延迟性。所以会导致中间状态的出现，所以导致很多系统选择了ap。这里就是对ap进行的补充。
软状态也被称为柔性状态，允许系统中的数据存在中间状态，并认为该中间状态不会影响系统的整体可用性。即允许系统在不同节点的副本之间进行数据同步的过程存在延迟。

2 基本可用
分布式系统在出现不可预知故障的时候，允许失去部分可用性。不过不等价于系统不可用
1允许响应时间上的损失。查询出现故障，响应增加一秒。
2允许系统功能上的损失 购物高峰时期消费者的降级页面。

3 最终一致性。ap中的最终一致。
最终一致性强调的是所有的数据副本，在经过一定时间的同步之后。最终都会达到一个一直的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致性。