一、数据库事务
1.1）什么是ACID
Atomicity 原子性
对于一个操作，要么全部提交，要么全部回滚。
Consistency 一致性
数据库中的数据符合现实世界中的约束，则这些数据符合一致性。比如性别约束男 & 女，人民币数值不能为负，出生地址不能为null，转账的总金额不能变等等。
Isolation 隔离性
对于同一个数据的操作，各个事务对于该数据状态的转换互相不可见
Durability 持久性
现实状态映射到数据库中，意味着对数据所有的改动都持久化到磁盘上
1.2）事务的状态都有哪些
1.3）事务并发执行时数据一致性问题有哪些
脏写对于多个事务操作同一数据时没有任何隔离性
脏读：一个事务（A）读取到了另一个
事务（B）修改过的数据
不可重复读：另一个事务（B）修改一个
针对某条件读前读后不一致
幻读：一个事务（A）根据
（select ... where vip='是'）查询了一些记录。A未提交时，另一个事务（B）写入了（insert、update、delete都行，以insert为例）一些符合上述搜索条件的记录（insert into ... values(3,700,'是') ）
针对某条件范围读前读后不一致
3）SQL事务隔离级别
隔离级别从上到下依次安全度递增，效率递减
二、分布式场景下事务及数据一致性问题
微服务数据一致性问题不可避免
2.1）水平分库
数据分流，分表也是一样的逻辑
2.2）垂直分库
关系型数据库一张表数据量上两三千万就会承压过大，采取在一个库中水平分表将数据分摊可减小压力；
水平分库是为了防止高并发情况下可能产生超出数据库连接的系统假死情况提供数据库的主从保证高可用性；
垂直分库是为了方便业务的解耦，也可以防止磁盘过大占用随机读影响的效率
一般情况下除了生意特别火爆，库存和支付不会很忙，只有订单会多一些则只需要针对订单表进行分表，这种情况下单体服务完全够用
三、分布式事务解决方案
3.1）刚性事务——XA
3.2）刚性事务——2PC
单点问题在于协调者挂掉参与者接收不到命令；性能问题在于每个参与者的效率不一样影响整体性能；一致性风险在于协调者通知参与者执行第二阶段时某一个参与者由于网络或其他问题没接收到命令而失去整体事务执行不一致
3.3）刚性事务——3PC
询问阶段解决了性能问题，超时可以自动提交解决了单点问题，询问阶段主要查询各个参与者数据库是否健康
3.4）柔性事务——可靠事务队列
比如当每隔一分钟重试五次全部失败，则有一个后台线程扫描行为表发现状态不是已完成则将总表的事务ID11111状态改为0表示应该整体行为失败
3.5）柔性事务——TCC
业务侵入式不强的框架在于不用框架时系统只需要去除一些注解仍然能运行——TCC和2PC的区别在于cancel阶段使我们自己实现，可在其中继续重试提交
3.6）柔性事务——SAGA
补偿区别于TCC的冻结在于没有中间状态，比如支付直接执行完扣钱之后其它事务失败需要整体回滚时由于已经执行扣钱所以就补偿再给账户充钱，而不是像冻结一样取消扣钱
3.7）柔性事务——基于数据补偿
需要回滚的时候先通过后镜像检测数据库中是否符合生成逆向SQL条件，不符合抛异常，符合再根据前镜像生成逆向SQL进行数据补偿——简单来说就是其它服务进行了不同于后镜像的脏写
刚性事务和柔性事务对比
四、Seata概述
4.1）什么是Seata
4.2）Seata的特色功能
基于数据补偿的AT模式为主，但在数据库是别人系统无法基于SQL回滚的情况下使用TCC模式辅助完成分布式事务
4.3）Seata中的角色
Server和Client使用Netty和dubbo交互，主要是Netty
4.4）Seata处理分布式事务的主要流程
TM向TC申请开启全局事务，TC向TM返回全局事务ID，RM开启后向TC进行注册分支，TC记录不同的Branch_ID，RM完成Commit后向TC发送状态，TC检测所有Branch_ID状态成功后向TM发送二阶段提交命令（也就是
），状态失败则回滚
