Seata入门系列（一）

CAP理论

CAP理论：一个分布式系统，不可能同时做到这三点，要么做到CP，要么做到AP

-   Consistency（一致性）
-   Availability（可用性）
-   Partition tolerance（分区容忍性）

①**一致性：** 对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。

②**可用性：** 任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。

③**分区容忍性：** 由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

# base理论
Base理论
基本可用、软状态、最终一致性

Seata 2PC

2PC：准备阶段 、 提交阶段

准备阶段：事务管理器给每个参与者发生准备请求，参与者在本地执行事务，**写入undolog和redolog**，此时没并没有提交事务，向事务管理器发送事务执行状态

提交阶段：事务管理器根据响应，若收到了执行失败或超时的消息，就通知每个参与者rollback并释放资源，参与者执行undolog中的数据；若收到所有参与者的执行成功的消息，就通知所有参与者进行提交并释放资源

· TC (Transaction Coordinator)-事务协调者，**维护全局和分支事务的状态**，驱动全局事务提交或回滚。

· TM (Transaction Manager)-事务管理器（**发起者**，同时也是RM的一种)定义全局事务的范围:开始全局事务、提交或回滚全局事务。

· RM (Resource Manager)-资源管理器(每个参与事务的微服务)**管理分支事务处理的资源**，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata-AT模式

2PC的演变  

一阶段：Seata会拦截业务sql，解析sql语句，找到跟新的数据，然后再sql执行前，将更新前的数据保存在undolog中，然后执行sql语句更新数据，更新之后的数据保存到redolog，最后生成行锁，这些操作都在本地事务中完成，保证一阶段的原子性（seata中的undolog与redolog并不是mysql中的undolog和redolog）（在这个阶段，各服务端执行本地事务，这些事务在各自的数据库中独立提交。Seata会在本地事务中捕获数据变更，并将这些变更记录在Seata的undo log中。这个阶段中，MySQL的事务机制被用来保证单个数据库操作的原子性和一致性。）

二阶段：负责整体的提交或回滚，如果一阶段中有本地事务没有通过，那么就执行全局回滚，否则全部提交，回滚就是用的undolog，（一旦所有参与的本地事务都提交，Seata的事务协调器（TC）会决定全局事务的最终状态（提交或回滚）。如果决定提交，则所有本地事务的提交将被视为最终状态；如果决定回滚，则Seata会使用undo log中的信息来恢复数据到事务开始前的状态。）通过回滚记录生成反向的更新SQL并执行，以完成分支的回滚，事务完成后释放所有资源，删除日志；

mysql中的undolog和redolog存储的是什么？

    Redo log记录了对数据页的物理修改，它包含了修改前的页状态和修改后的页状态，但更常见的是记录修改操作本身(指令)，以便在系统崩溃后可以重放这些操作来恢复数据页到最新的已提交状态。

    Undo log记录了事务开始前的数据状态（before image）和事务结束后的数据状态（after image），以及足够的信息来重建数据页的先前版本。Undo log主要用于事务的回滚和MVCC（多版本并发控制）。如果事务需要回滚，InnoDB可以使用Before Image来恢复数据到事务开始前的状态（回滚操作不是通过逆序执行反向SQL语句来完成的，而是通过直接利用undo log中的信息来恢复数据到事务开始前的状态。这一过程并不涉及生成和执行反向SQL语句。）

seata中的undolog和redolog 与 mysql中的undolog和redolog区别？

    Seata中的undo log和redo log概念与MySQL中的undo log和redo log有相似之处，但它们在功能和实现上是不同的，服务于不同的目的。

    Seata的Undo Log vs MySQL的Undo Log

    目的：

            Seata：Seata的undo log主要用于分布式事务的回滚。它记录了本地事务在开始时的数据状态，以便在分布式事务需要回滚时，可以将数据恢复到事务开始前的状态。

            MySQL：MySQL的undo log用于支持事务的回滚和多版本并发控制（MVCC）。它记录了事务开始时的数据状态和事务执行后的数据状态，以及足够的信息来重建数据页的先前版本。

    存储内容：

            Seata：Seata的undo log存储的是业务数据的before image，即事务开始前的数据状态，以及事务执行的SQL语句和参数，以便于回滚。

            MySQL：MySQL的undo log存储的是数据的逻辑变化，包括事务开始前的数据状态和事务执行后的数据状态，以及必要的信息来恢复数据页的先前版本。

    存储位置：

            Seata：Seata的undo log通常存储在Seata配置的undo_log表中，这是一个由Seata管理的特殊表，与业务数据分离。

            MySQL：MySQL的undo log存储在InnoDB的undo段中，这些段位于系统表空间或独立的undo表空间中。

    Seata的Redo Log vs MySQL的Redo Log

    目的：

            Seata：Seata的redo log概念主要体现在事务的执行顺序和状态跟踪上，而不是用来恢复数据。在Seata的AT模式中，redo log更多地体现在事务元数据的记录上，如事务的ID、状态、参与的节点等。

            MySQL：MySQL的redo log用于记录数据页的物理更改，确保在系统崩溃后能够重放这些更改，从而使数据恢复到最新的已提交状态。

    存储内容：

            Seata：Seata的redo log概念在实现上并没有像MySQL那样有明确的redo log文件，它更多地是事务状态和执行流程的记录。

            MySQL：MySQL的redo log记录的是对数据页的物理修改，包括页的地址和修改的具体内容。

    存储位置：

            Seata：Seata的redo log相关信息通常存储在内存中或通过消息队列等方式进行传输和存储，用于协调事务的提交或回滚。

            MySQL：MySQL的redo log存储在redo log文件中，这些文件是循环使用的。

    总之，尽管Seata和MySQL都使用了undo log和redo log的概念，但它们的实现和功能是为了满足各自系统的需求，因此在细节上存在显著差异。Seata的undo log和redo log更多地是为了支持分布式事务的协调和恢复，而MySQL的undo log和redo log则是为了支持单个数据库实例的事务管理和数据恢复。