1.什么是事务
将一组任务看成一个整体，全部完成或者全部不完成
2.事务的四大特性
1.原子性：将事务看成一个整体，不可分割
2.隔离性：事务与事务互不影响，相互隔离
3.持久性：一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作
4.一致性：一个事务执行之前和执行之后都必须处于一致性状态
3.InnoDB如何保证原子性和持久性的
1.保证原子性：是利用Innodb的undo log。
undo log名为回滚日志，是实现原子性的关键，当事务回滚时能够撤销所有已经成功执行的sql语句，他需要记录你要回滚的相应日志信息。
例如:
(1)当你delete一条数据的时候，就需要记录这条数据的信息，回滚的时候，insert这条旧数据
(2)当你update一条数据的时候，就需要记录之前的旧值，回滚的时候，根据旧值执行update操作
(3)当年insert一条数据的时候，就需要这条记录的主键，回滚的时候，根据主键执行delete操
undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。
2.保证持久性
是利用了redo log。Mysql是先把磁盘上的数据加载到内存中，在内存中对数据进行修改，再刷回磁盘上。如果此时突然宕机，内存中的数据就会丢失。redo log包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。innodb通过force log at commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。也就是说提交了两个日志文件。
4.事务并发问题有哪些
1.脏读：一个事务读取到了另外一个事务未提交的数据，读到其他事务的未提交的“更新”数据
2.不可重复读：同一个事务中，多次读取到的数据不一致
3.幻读：一个事务读取到了另外一个事务未提交的数据，只是读到的是其他事务“插入”的数据
5.解释一下事务并发丢失更新问题，如何解决
1.原因
第一类丢失更新(回滚丢失，Lost update) （通过设置隔离级别可以防止 Repeatable Read）
第二类丢失更新(覆盖丢失/两次更新问题，Second lost update) A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失
2.解决
基本两种思路，一种是悲观锁，另外一种是乐观锁；
简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败；另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作。
6.说一下事务的执行流程(Undolog+Redolog)
事务的隔离性由锁来实现，原子性，一致性，持久性通过数据库的redo log 和 undo log来完成，redo log称为 重做日志，用来保证事务的原子性和持久性。undo log用来保证事务的一致性。redo 和 undo 的作用都可以视为是一种恢复操作，redo恢复提交事务修改的页操作，而undo 回滚行记录到某个特定版本。因此两者记录的内容不同，redo通常是物理日志，记录的是页的物理修改操作，undo 是逻辑日志，根据每行记录进行记录。
7.事务隔离级别有哪些，分别能解决什么问题
1.读未提交(read-uncommitted)：能读到未提交的数据。会出现脏读、不可重复读、幻读。
2.读已提交(read-committed)：读已提交的数据。会出现不可重复读和幻读。
3.可重复读(repeatable-read)：mysql默认的事务隔离级别，查询的都是事务开始时的数据。只会出现幻读。
4.串行读(serializable)：完全串行化读，每次都会锁表，读写互相阻塞。最高隔离级别，不会出现脏读，不可重复读，幻读。但会大大影响系统的性能，一般不用。
8.InnoDB事务隔离的实现原理是什么
通过事务的隔离级别
9.什么是分布式事务
分布式事务就是指在分布式环境下，是为了保证不同数据库的数据一致性。
10.分布式事务你知道哪些解决方案？
1.2pc:2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段( Prepare phase).提交阶段( commit phase ) , 2是指两个阶段, P是指准备阶段, C是指提交阶段。
1.基于XA协议的两阶段提交方案:数据库层面实现的
2.Seata的两阶段提交方案:分布式事务框架，通过对本地关系数据库的分支事务的协调来驱动完成全局事务,是工作在应用层的中间件
2.TCC
3.可靠消息最终一致性
4.最大努力通知
11.Seata相比传统2PC有什么区别，以及优点？
架构层次方面
传统2PC方案的RM实际上是在数据库层, RM本质上就是数据库自身,通过XA协议实现,而Seata的RM是以jar包的形式作为中间件层部署在应用程序这一侧的。
两阶段提交方面
传统2PC无论第二阶段的决议是commit还是rollback ,事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1就将本地事务提交,这样就可以省去Phase2持锁的时间,整体提高效率。
12.SeataTC,TM,RM的含义，以及作用？
Transaction Coordinator(TC):事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运行状态,接收TM指令发起全局事务的提交与回滚,负责与RM通信协调各各分支事务的提交或回滚。 相当于是一个软件需要单独部署
Transaction Manager (TM):事务管理器, TM需要嵌入应用程序中工作,它负责开启一个全局事务,并最终 向TC发起全局提交或全局回滚的指令。
Resource Manager (RM):控制分支事务, 负责分支注册、状态汇报,并接收事务协调器TC的指令, 驱动 分支(本地)事务的提交和回滚。
13.解释一下Seata的工作原理
1.用户服务的TM向TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID。
2.用户服务的RM向TC注册分支事务,该分支事务在用户服务执行新增用户逻辑,并将其纳入XID对应 全局事务的管辖。
3.用户服务执行分支事务,向用户表插入一条记录。
4.逻辑执行到远程调用积分服务时(XID在微服务调用链路的，上下文中传播)。积分服务的RM向TC 注册分支事务,该分支事务执行增加积分的逻辑,并将其纳入XID对应全局事务的管辖。
5.积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务。
14.你知道TCC吗，它有什么样的优缺点？
TCC, 是基于补偿型事务的AP系统的一种实现, 具有弱一致性
补偿理解：按照事先预定的方案去执行，如果失败了就走补偿方案(撤销)
优点
异步执行效率高
TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-/confirm/i-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可.
TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行.
缺点
对应用的侵入性强。业务逻辑的每个分支都需要实现try、/confirm/i、cancel三个操作，应用侵入性较强，改造成本高。实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，/confirm/i和cancel接口必须实现幂等-一个操作多次循环都是一样。
使用场景
严格一致性 | 执行时间短 | 实时性要求高 |
15.你能简单描述一下你在项目中是如何集成Seata的吗
1.导入依赖
2.yml配置seata
3.配置文件
1.registry.conf TC存储RM注册信息的文件配置
2.创建file.conf，个大微服务的RM和TC之间的通信配置
4.DataSourse代理配置
5.开启全局事务
6.undolog日志
