SpringCloud高级-seata

事务的特征有哪些，分别是什么意思

以下是在本地事务中，也是就是传统的单机事务，是以及在spring中使用注解也是@Transational

A  原子性  在一个事务的所有操作，要么全部成功，要么全部失败
C  一致性  事务执行的前后，数据是保持一致性，例如转账例子
I   隔离性  多个并发的事务应该要相互隔离
     如果隔离性不好，则产生
        脏读   一个事务读取到另一个事务未提交的数据（细节：脏读又称无效数据的读出，是指在数据库访问中， 事务 T1将某一值修改，然后事务T2读取该值，此后T1因为某种原因撤销对该值的修改，这就导致了T2所读取到的数据是无效的，值得注意的是，脏读一般是针对于update操作的。）
        不可重复读   一个事务读到到另一个事务的已经提交更新数据（细节：不可重复读是指在事务1内，读取了一个数据，事务1还没有结束时，事务2也访问了这个数据，修改了这个数据，并提交。 紧接着，事务1又读这个数据。 由于事务2的修改，那么事务1两次读到的的数据可能是不一样的，因此称为是不可重复读。）
        幻读  一个事务多次读取结果（新增的已提交的数据）不一致（细节：幻读是事务非独立执行时发生的一种现象。 例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。）

     
D  持久性    事务一旦提交，则永久保存，即使故障也不丢失

 

 

CAP定理和BASE理论

CAP定理，C是值一致性，A指可用性，P指容错性。
CAP定理，在说P必然存在的，C和A只能选择一个特性。在CAP定理，只存在CP或AP。

 CAP定理矛盾点

在分布式系统中，系统间的网络不能保证不会出故障，而服务却不能停止服务，所以P不可避免

当P出现时：

如果我们要保证一致性，就只能等网络恢复，完成数据同步后，整个集群才能对外提供服务，在等的过程中，服务就处于阻塞状态不能用。

如果我们要保证可用性，就不等网络恢复，但是节点之间的数据就不一致了。

 

 

BASE理论，是对CAP一种补充，也是解决CAP的一种思路：

三种思想：

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。

Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
BA指基本可用，S代表软状态，E代表最终一致性

CAP定理说如果选择了一致性，就放弃了可用性，但BASE理论说选择了一致性，只是损失了部分可用，意味处于基本可用。
CAP定理说如果选择了可用性，就放弃了一致性，但BASE理论说选择了可用行，只是存在临时的不一致状态，这种临时的不一致性称为软状态，这种软状态过后达成最终一致性。

分布式事务最大的问题就是各个分支事务之间的一致性，我们可以借鉴CAP和BASE理论，得出两种解决思路：

AP模式：各个分支事务分别执行和提交，允许出现结果不一致，然后弥补恢复数据就行，实现最终一致性。（强可用，弱一致）

CP模式：各个分支事务执行后相互等待，最后全部提交，全部回滚，达成强一致，但是呢，在等待过程中，事务不可用，也就是弱可用状态（强一致，弱可用）

Seata的AT模式是AP还是CP？解释一下Seata的AT模式的原理

AT模式是一种AP模式（强可用，弱一致性）。

Seata的AT模式的执行流程大概就这样：
Seata架构中存在三大组件，TC（TC是事务协调者），TM（事务管理器）和RM（资源管理器）。
 首先，由TM向TC发出开始全局事务的请求，TC在全局事务表中记录数据。
 接着，由TM通知各个的RM调度各自的分支事务，这时分支事务开始执行啦。分支事务先向TC进行注册分支事务，开始执行SQL语句并提交，在SQL执行的前后，AT模式会把更新记录的前后数据保存到undo_log日志表中作为数据快照，再上报事务执行结果给TC。
 最后，TC收集到所有分支事务的执行状态，进行分析，决定是否提交还是回滚，如果提交，则TC向所有RM发出删除undo_log日志记录的请求。如果回滚，则TC向所有RM发出读取undo_log数据快照做数据恢复的请求。

在AT的执行过程中，我了解到会有脏读的情况存在，Seata考虑到了，利用全局事务锁表，在每个分支事务提交之前，判断是否能获取全局事务锁，决定是否提交，这样就控制脏写。

 阶段一RM的工作：注册分支-->记录undo-log（数据快照）-->执行业务sql并提交-->报告事务状态

阶段二RM的工作：提交时：删除un-log即可

                               回滚时：根据un-log恢复数据到更新之前

 脏写：所谓脏写，就是我刚才明明写了一个数据值，结果过了一会却没了。 而它的本质就是事务 B 去修改了事务 A 修改过的值，但是此时事务 A 还没提交，所以事务 A 随时会回滚，导致事务 B 修改的值也没了，这就是脏写的定义。