有关事务的补充
一、ACID： 是指在数据库管理系统（DBMS）中，事务(transaction)所具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）
原子性：一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。
隔离性：当两个或者多个事务并发访问（此处访问指查询和修改的操作）数据库的同一数据时所表现出的相互关系。事务隔离分为不同级别，包括读未提交(Read uncommitted)、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上，通常一个分布式事务中会涉及对多个数据源或业务系统的操作。一个分布式事务可以看做是由多个分布式的操作序列组成，通常可以把这一系列分布式的操作序列称为子事务。由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂-
不能保证 分区的不出错的情况下 C和A 只能二选一
为什么分布式环境下CAP三者不可兼得呢？ 由于上面已经提到对于分布式环境下，P是必须要有的，所以该问题可以转化为：如果P已经得到， 那么C和A是否可以兼得？可以分为两种情况来进行推演： (1) 如果在这个分布式系统中数据没有副本，那么系统必然满足强一致性条件，因为只有独本数据，不会出现 数据不一致的问题，此时C和P都具备。但是如果某些服务器宕机，那必然会导致某些数据是不能访问的,那A 就不符合了。 (2) 如果在这个分布式系统中数据是有副本的，那么如果某些服务器宕机时，系统还是可以提供服务的，即 符合A。但是很难保证数据的一致性，因为宕机的时候，可能有些数据还没有拷贝到副本中，那么副本中提供 的数据就不准确了。
BASE模型在理论逻辑上是相反于ACID（原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）模型的概念，它牺牲高一致性，获得可用性和分区容忍性。
总结：
ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。
1.mysql的隔离级别
Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能 也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见 已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务 的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过 理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数 据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行, InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决 了该问题。 Serializable（可串行化） 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读 的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。 出现问题 这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如： 脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因， 前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程 中间插入了一个事务更新的原有的数据。 幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据， 而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前 所没有的。
2.mysql怎么实现MVCC
3.spring的事务传播行为、什么情况下事务失效？
REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED。
pring事务的传播在类内部方法中调用时是失效的
因为 spring 事务管理是通过 AOP 来实现的，外部类调用时会先调用代理类，代理类再调用实际类。
而类内部调用时，是实际类内部调用，不经过代理类，而事务管理实在代理类层面实现，所以类内部调用事务管理会失效。
Spring事务失效场景 数据库引擎不支持事务，比如MyISAM 入口方法不是public，这一点由Spring的AOP特性决定的，理论上而言，不public也能切入，但spring可能 是觉得private自己用的方法，应该自己控制，不应该用事务切进去吧）。另外private 方法, final 方法 和 static 方法不能添加事务，加了也不生效。 Spring事务管理默认只支持运行期异常进行回滚（至于为什么spring要这么设计：因为spring认为Checked的 异常属于业务的，coder需要给出解决方案而不应该直接扔该框架） 没有启用事务和切面 类是否被正确代理 业务和事务要在同一个线程，否则事务也不生效 默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法 并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。
nacos 既可以作为注册中心 也可以作为配置中心
注册中心：提供服务发现
配置中心：提供配置信息
==nacos的命名空间做环境隔离
Seata事务管理中有三个重要的角色：
1.TC (Transaction Coordinator) 事务协调者：维护全局和分支事务的状态，协调全局事务的提交或回滚
2.TM (Transaction Manager) 事务管理者：定义全局事务的范围，开始全局事务、提交或回滚全局事务
3.RM (Resource Manager) 资源管理者：管理分支事务处理的资源，与TC交谈已注册分支事务和报告分支事务的状态 并驱动分支事务提交或回滚
XA模式的优点是什么？ 事务的强一致性，满足ACID原则。 常用数据库都支持，实现简单，并且没有代码侵入 XA模式的缺点是什么？ 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差 依赖关系型数据库实现事务
简述AT模式与XA模式最大的区别是什么？ XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。 XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。 XA模式强一致；AT模式最终一致
AT模式的优点： 一阶段完成直接提交事务，释放数据库资源，性能比较好 利用全局锁实现读写隔离 没有代码侵入，框架自动完成回滚和提交 AT模式的缺点： 两阶段之间属于软状态，属于最终一致 框架的快照功能会影响性能，但比XA模式要好很多
TCC模式的每个阶段是做什么的？ Try：资源扣除与冻结 Confirm：删除冻结数据 Cancel：冻结资源的恢复 TCC的优点是什么？ 一阶段完成直接提交事务，释放数据库资源，性能好 相比AT模型，无需生成快照，无需使用全局锁，性能最强 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库 TCC的缺点是什么？ 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦 软状态，事务是最终一致 需要考虑Confirm和Cancel的失败情况，做好幂等处理
分布式的模式：
XA：利用的式数据库本身的事务，一阶段时不提交事务、二阶段才提交或回滚
AT：全局事务锁，一阶段事务提交，通过undo log 快照恢复 （但是 存在 脏读的问题 ）
TCC：try 扣除资源与备份、confirm成功时删除备份、cancel失败恢复资源
TCC 存在的问题 空回滚 和 事务悬挂 空回滚：try被阻塞了，执行了cancel,没有需要回滚的事务 事务悬挂：try被阻塞了, 导致先执行了cancel，在恢复了try 解决：空回滚时,添加记录代表执行过了cancel try恢复时,判断时候存在cancel执行过的记录,如果有就不去执行后续
Seata的工作原理：
在seata处理微服务分布事务 框架中有三个重要的角色
1.RM（ResourceManager） 资源管理者
[可以理解为我们的一个一个的微服务，也叫做事务的参与者]
2.TM （TransactionManager） 事务管理者
[也是我们一个微服务 但是微服务的老大，充当全局事务的发起者(决定了全局事务的开启，回滚，提交)
自带 @GlobalTransactional ]
3.TC（全局事务的协调者）
[这就是我们的Seata-server 用来保存全局事务、分支事务、全局锁等记录 然后通知各个RM进行回滚或者提交事务]
和钱相关的一定要保证强一致性！(AT)
------
描述一下seata的执行流程 用到了什么方法？？？
扫一扫
355
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
