ACID原则
事务内的操作都是要么全部成功，要么全部失败
一致性
所有事务开始前数据是一致的，事务提交后数据也是一致的
隔离性
各个事务之间的操作互不影响
持久性
事务提交后数据的保存是永久性的
事务的默认传播级别。支持当前事务，如果不存在当前事务就新建一个。
开启一个事务，如果当前事务存在，则挂起当前事务，执行新事务
如果当前有一个事务正在运行，则当前事务应该被运行在一个嵌套事务里面，该嵌套事务可以进行独立的提交或回滚；如果当前没有事务正在运行，相当于PROPAGATION_REQUIRED
支持当前事务，如果当前事务不存在，则以非事务的方式去运行
不支持当前事务。以非事务方式运行，如果当前事务存在则挂起该事务。
必须运行在一个事务里面，否则抛异常
不能运行在事务里面，如果运行在事务里面则报异常。
事务A可以读取到事务B未提交的事务，会有脏读，幻读，不可重复读的问题
Oracle和SqlServer的默认隔离级别，会有不可重复读的问题
MySql的默认隔离级别，可能会有幻读的问题
事务的最高隔离级别，数据安全性高，但是会加行锁，造成大量的锁竞争，极度影响性能，只有在无并行和非常要确保数据强一致性的情况下使用。
脏读是事务A读取到了事务B已回滚的数据，导致了脏读
幻读是事务A读取到了事务B已提交的数据
在同一事务中多次查询结果不一致
首先Spring中并没有事务，他只是提供了对数据库事务管理的一个封装，外面可以通过声明式事务的配置，使得开发人员可以从一些复杂的事务处理里面去脱离出来，我们不需要再去关心数据库的连接，关闭，事务的开启，提交回滚等操作，可以更聚焦在业务的开发里面。解决的是单个数据库里面多个表之间的操作问题。
分布式事务解决的是多个数据库事务操作的一致性问题，一般用Seata这种分布式事务的解决方案，与Spring整合。传统的关系型数据库不支持跨库的操作。所以得引入分布式事务解决方案。
在微服务架构中，由于数据库和应用服务的拆分，导致原来在一个事务单元中的多个DML操作，编程跨进程，跨数据库的多个事务单元的多DML操作，而传统的数据库事务是无法解决这些问题的。所以就引出了一个分布式事务的概念。
分布式事务要解决的是跨网络节点的多个事务一致性问题。业内常见的解决方案有两种。
第一种是强一致性。所有的事务参与者要么全部成功，要么全部失败。全局事务协调者需要知道每一个事务的执行状态。再去根据状态来决定数据的提交或回滚。
第二种是最终一致性，也叫弱一致性。允许多个网络节点的数据状态不一致，但是在最终的某个时间节点一定会达成数据一致。
根据CAP定理可知，强一致性会对系统的性能和可用性造成一定的影响。所以对于数据一致性要求不是很高的场景我们会使用最终一致性算法。