数据库事务（Transaction）是访问并更新数据库中各种数据项的一个程序执行单元。
事务的4个基本特征（ACID）：
- Atomic（原子性）：事务中包含的操作被看作一个整体的业务单元。
- Consistency（一致性）：事务完成时，必须使所有的数据保持一致状态。
- Isolation（隔离性）：多个引用程序线程访问同一数据，这样的数据库的数据就会在各个不同的事务中被访问。
- Durability(持久性）：事务一旦提交，其结果就是永久性的。
数据库的四种隔离级别：
- 读未提交（Read Uncommitted）： 所有事务可以看到其它未提交事务的执行结果，可能会出现脏读（Dirty Read）
- 读已提交（Read Committed）：一个事务只能看见已经提交的事务所做的改变，大多数数据库的默认隔离级别（mysql除外），可能会现不可重复读：一个事务内两次读取数据不同，由于被另一个务务个性并提交）
- 可重复读（Repeatable Read）确保同一个事务的多个实例在并发读取数据时，会看到同样的数据行。一可能会出现幻读：和不可重复读一样，区别为出现了新增或删除数据，让读取者产生了幻觉，而不是数据不准确。
- 串行化（Serializable），事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。
mysql默认的隔离级别是：可重复读（REPEATABLE-READ)，可通过如下语句查询：
select @@tx_isolation;
分布式事务：
事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上。
分布式事务一致性细化：
强一致性：任何一次读操作都是读取的数据的最近一次写入的数据。任意时间，所有节点的数据是一样的。
弱一致性：数据更新后，容忍后续的访问只能访问到部分或全部访问不到的情况。
最终一致性：不保证在任意时间任意节点的同一份数据是相同的，但一段时间的同步后，节点的数据最终会达到一致性状态。
CAP原则：
指在一个分布式系统中，Consistency（一致性）、Availiability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
- 一致性：在分布式系统中，所有数据在同一时间是同样的值。
- 可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。主要是为了防止脑裂。
- 分区容错性：分布式系统在遇到网络故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。分布式系统中，节点之间本来是连通的，然后由于某些故障，使用节点之间不连cpe了，这时网络就划分成了几块区域，数据就散布在这些不连通的区域中，叫分区。若一个数据只保存在一个节点，访问其它节点时就无法读取该数，这是分区是无法容忍的。提高分区容忍度的方法是数据复制到多个结点中，但这样数据同步问题可能会有不一致的情况，这就带来一致性问题。要保证一致性，更新数据时就需要保证所有节点写成功，这就会带来可用性问题。
BASE理论：
BASE理论是基于CAP理论逐步演化而来的，是CP和AP权衡的结果，核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性。
- BA： Basically Available：基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用；也可以体现在响应时间上的损失。
- Soft state： 软状态：数据同步允许一定的延迟。
- Eventually consistent 最终一致性：系统中所有数据副本，在经过一段时间的同步后，最终达到一个一致的状态，不要求实时。
在分布式场景下基于BASE理论，出现了柔性事务的概念。通常会允许数据有不一致的状态，这时候就需要保证操作的幂等性。
两阶段提交/XA
XA（eXtended Architecture)是指由X/Open组织提出的分布式交易处理的规范。是一个分布式事务协议。协议主要定义了事务管理器TM（Transaction Manager， 协调者）和资源管理器（Resource Manager， 参与者）之间的接口。其中，资源管理器往往由数据库实现；事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
XA事务是基于两阶段提交（Two-phaseCommit, 2PC)协议实现的，可以保证数据的强一致性，缺点是性能不好（协调者和参与者交互过于频繁），且无法满足高并发场景。
- 第一阶段（prepare):事务管理器向所有本地资源管理器发起请求，询问是否是ready状态，所有参与者都将本事务能否成功的信息反馈给协调者
- 第二阶段（commit/rollback)：事务管理器根据所有本地资源管理器的反馈，通知所有本地资源管理器，上步调一致的在所有分支上提交或者回滚。
TCC
TCC事务机制,同2PC差不多，解决了几个缺点：
- 解决了协调者单点，由主业务方发起并完成这个ovtl活动
- 同步阻塞：引入超时，超时后进行补偿，并且不会锁定整个资源。
- 数据一致笥，由业务活动管理器控制一致性。
T Try；C Confirm； C Cancel，三个阶段。基于TCC实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为Try、Confirm、Cancel三个接口中，代码实现复杂度高，对业务也是有侵入的。
Reference
https://xiaomi-info.github.io/2020/01/02/distributed-transaction/