这里先抛出一个问题：什么是事务？什么是分布式事务？
由于隔离机制做的不恰当，在并发事务操作中我们经常会遇见的三个问题
(1)脏读（Dirty Read）：脏读是指一个事务在读取了另一个事务未提交的数据时发生的情况。假设事务A更新一个数据，但是还没有提交，事务B读取了这个未提交的数据，然后事务A回滚了或者修改了这个数据，这时事务B读取到的数据实际上是不正确的，也就是脏数据。脏读可能导致数据的不一致性。
(2)幻读（Phantom Read）：幻读是指一个事务在读取了另一个事务已提交的数据后，再次读取同一个范围的数据时，发现有新的数据出现，就好像发生了幻觉一样。例如，事务A查询某个范围的数据，事务B在事务A完成后插入了一条符合该范围的数据，然后事务A再次查询同一个范围的数据，发现多了一条数据。这个现象称为幻读。幻读可能导致查询结果的不一致性。
(3)不可重复读（Non-repeatable Read）：不可重复读是指一个事务在读取了某个数据后，另一个事务对该数据进行了修改或删除操作，导致第一个事务再次读取该数据时，获取到了不同的结果。例如，事务A读取某个数据，事务B修改了该数据并提交，事务A再次读取同一个数据时，发现数据的值不一样了。这种现象称为不可重复读。不可重复读可能导致读取操作的不一致性。
*需要注意的是，脏读、幻读和不可重复读，解决这些问题一般需要采取如下措施：
锁机制：如使用悲观锁或乐观锁来保证数据的一致性和完整性。
事务隔离级别：通过设置合适的事务隔离级别来避免脏读、幻读和不可重复读问题。
业务设计：在数据的读写操作中，根据实际业务需求进行合理的设计，避免并发操作导致的问题。
带着问题分析事务。。。。
传统数据库事务
一、事务的特性：
Atomicity 原子性：事务的所有操作要末全部成功，要末全部失败。
Consistency一致性:要保证事务开启时到事务结束后数据状态一致。
Isolation隔离性:要保证多个事务之间操作相互之间不影响，互相隔离。 比如说这边转账和你支付不互相影响。
Durability持久性：事务一旦提交，则是永久的保存到磁盘，不可逆
二、事务的隔离级别
（1）读未提交：再一个事务执行写操作的时候，另一个事务进来执行读操作，读取了第一个事务写未提交的东西，导致你读到了没有修改完成的数据，如果第一个事务提交的事务提交的时候回滚了，造成你读的数据可能根本不存在。产生脏读，幻读，不可重复读的问题。
（2）读已提交：再一个事务进行写操作的时候，而无法看到未提交的数据或在查询执行期间其它事务提交的数据，会产生幻读、不可重复读的问题,oracle默认的隔离级别就是。
（3）可重复读：在可重复读级别下，事务可以多次读取同一行数据，并且在事务执行期间，其他事务无法修改这些数据。这意味着，（在可重复读的时间里面无视你修改）如果一个事务在读取某行数据后，另一个事务修改了该行数据，第一个事务再次读取该行数据时，仍然会得到原来的值，而不是修改后的值。可能会产生幻读问题他也可能因为你插入数据，我再读同一行的时候发现不一样，另起一行展示这个数据。mysql默认的隔离级别是可重复读
（4）串行化：没有任何问题，但是相当于锁表，效率极低。所以这种方案不用
在程序中事务执行隔离级别是默认的，如果你用的是MySql那就是可重复读隔离级别，当然我们是可以设置的在我们的程序也可以设置事务特性，就是根据Transactional里面的isolation方法，设置几大隔离级别。
我当前在程序中执行的就是对事务的默认隔离级别设置成了读已提交。
传统事务在不同应用上的事务控制，
JDBC：Connection 创建不同的连接
Mybatis：SqlSession 配置数据库的链接文件，读取配置文件形成一个输入流，获取连接的sqlSession对象。
public class MyBatisUtil { private static SqlSessionFactory sqlSessionFactory; //静态代码块 static { try { //加载配置文件，得到数据流 InputStream is = Resources.getResourceAsStream("SqlMapConfig.xml"); sqlSessionFactory = new SqlSessionFactoryBuilder().build(is); } catch (IOException e) { throw new RuntimeException(e); } } //SqlSessionFactoryBuilder：这是MyBatis提供的建造者模式的构建器类，用于构建SqlSessionFactory对象 //build(resourceAsStream)：这是SqlSessionFactoryBuilder类的build方法，用于从指定的输入流（resourceAsStream）中构建SqlSessionFactory对象。 resourceAsStream：这是一个输入流，通常用于读取MyBatis配置文件，其中包含关于数据库连接信息、映射文件位置等配置。 //用构建的SqlSessionFactory对象,使用openSession方法创建一个SqlSession对象，可以通过该实例进行数据库操作。 public static SqlSession getSqlSession(){ return sqlSessionFactory.openSession(); } //提交事务 和 释放资源 public static void close(SqlSession sqlSession){ if(sqlSession !=null){ sqlSession.commit(); sqlSession.close(); } } }
Spring：基于运行时异常的声明式事务
分布式事务
概念：在分布式环境中，出现的事务问题。
分布式就是一个项目分成多个模块，每个模块都是一个独立的服务都有自己的数据库，
但是在一个项目中难免造成服务调服务，再通过其他服务调他的数据库，这就造成了事务的复杂性。
但是分布式对比传统事务一个是刚性事务，一个柔性事务：有时间弹性，达到最终一致性。
比对传统事务
分布式理论
cap理论
- Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
、- Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
、- Partition tolerance （分区容错性）：Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。容忍出现分区的问题。
cp:在一定时间内，等待集群节点进行数据同步后，对外提供访问
ap:在任何时间内，都对外访问，但是得到的数据可能不一样
base理论
对CAP理论的一种补充，放弃强制一致性，追求最终一致
他有三个思想:
Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。譬如电商大促，为了应对大流量，暂时停止注册服务，这时注册服务就不可用，但是整个系统是可用的，所以叫基本可用
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
比如订单状态：待付款、已付款待发货、已发货、已签收、已结束
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
分布式事务解决思路：
