数据库事务特性
数据库事务具备ACID四大特性：
- 原子性：是指事务操作时具备原子操作的，就是说整个过程要么全部成功，要么全部失败回滚。
- 一致性：是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处以一致性状态。比如在做多表操作时，多个表要么都是事务后新的值，要么都是事务前的旧值。
- 隔离性：是指多个用户并发访问数据数据库时，数据库为每个用户执行的事务，都不能被其他的事务所干扰，事务之间相互隔离。
- 持久性：是指一个事务一点执行操作成功，就是对数据库里面的数据操作是永久性的。
事务的并发问题
数据库在并发访问的时候会出现哪些问题？有思考过吗？
- 脏读：是指一个事务在处理过程中读取了其他未提交的事务里的数据。比如：小张转帐给 小王 500元人民币，小王 余额增加后但事务还没有提交完成，此时如果另外的请求中获取的是 小王增加后的余额，这就发生了脏读。如果这个过程中事务失败回滚时，小王的余额就不应该增加的。
- 不可重复读：是指对数据库中的某个数据，多次读的数据结果不一致。这是因为在这个过程中有其他事务在修改并提交。
- 幻读：是指两次查询结果，第二次查询返回结果跟第一次查询返回结果不同，幻读记录的是增加或删除的，导致两次相同条件获取的结果记录数不同。而不可重复读是对同一条记录，两次读取的值不同。
事务的隔离级别
事务的隔离级别有四种：
第一个隔离级别是读未提交的，最低的隔离级别，这个隔离级别就是可以读取到其他事务未提交的内容，会发生脏读，不可重复读，幻读等问题。
第二个隔离界别是读已提交的，就是只能读取到其他事务已经提交的数据。这个隔离级别可以解决脏读问题。
第三个隔离级别是可重复读，可以保证整个事务过程中，对同数据的多次读取结果是相同的。MySQL 默认的隔离级别就是可重复读。 这个级别可以解决脏读和不可重复读的问题。
第四个隔离级别是串行化，最高的隔离级别，所有事务操作都依次顺序执行。这个级别会导致并发度下降，性能最差。可以解决所有的并发问题。
分布式事务解决方案
1.XA 协议
XA协议是保证强一致性的刚性事务。实现方式有两段式提交和三段式提交。
两段式提交需要有一个事务协调者来保证所有的事务参与者都完成了第一阶段的准备工作。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务执行第二阶段提交。一般场景下两段式提交已经能够很好得解决分布式事务了，然而两阶段在即使只有一个进程发生故障时，也会导致整个系统存在较长时间的阻塞。三段式提交通过增加 pre-commit 阶段来减少前面提到的系统阻塞的时间。三段式提交很少在实际中使用，了解一下就可以了。
2.TCC
TCC是满足最终一致性的柔性事务方案。TCC 采用补偿机制，核心思想是对每个操作，都要注册对应的确认和补偿操作。
它分为三个阶段：
- Try 阶段主要对业务系统进行检测及资源预留；
- Confirm 阶段对业务系统做确认提交；
- Cancel 阶段是在业务执行错误，执行回滚，释放预留的资源。
3.消息一致性方案
基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么都成功要么都失败。下游应用订阅消息，收到消息后执行对应操作。
4.阿里云中的全局事务服务 GTS
阿里云中的全局事务服务 GTS，对应的开源版本是 Fescar。
全局事务服务（Global Transaction Service ，简称GTS）用于实现分布式环境下特别是微服务架构下的高性能事务一致性，可与 RDS、MySQL、PostgreSQL 等数据源，Spring Cloud、Dubbo、EDAS 及其他 RPC 框架，消息队列等中间件产品配合使用，实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合
Fescar 基于两段式提交进行改良，剥离了分布式事务方案对数据库在协议支持上的要求。使用 Fescar 的前提是分支事务中涉及的资源，必须是支持 ACID 事务的关系型数据库。分支的提交和回滚机制，都依赖于本地事务来保障。 Fescar 的实现目前还存在一些局限，比如事务隔离级别最高支持到读已提交级别。
GTS包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。
GTS Client主要用来界定事务边界，完成事务的发起与结束。
- GTS RM完成事务分支的创建、提交、回滚等操作。
- GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。
GTS和微服务集成的结构图如上图所示，GTS Client需要和业务应用集成部署，RM与微服务集成部署。
GTS是一款分布式事务中间件(具体地址)，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。更多GTS资料请访问创始人微博GTS创始人微博地址。
