BASE理论
既然分布式系统要遵循CAP定理，那么问题来了，我到底是该牺牲一致性还是可用性呢？如果牺牲了一致性，出现数据不一致该怎么处理？
人们在总结系统设计经验时，最终得到了一些心得：
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
以上就是BASE理论。
二阶段提交
在分布式系统中，二阶段提交（Two-Phase Commit，简称 2PC）是一种经典的协议，用于保证多个参与方在分布式事务中的一致性。
2PC 协议由两个阶段组成：
- 准备阶段（Prepare Phase）：
- 协调者（通常是事务管理器）向所有参与方发送准备请求，并等待它们的响应。参与方执行本地事务，并将事务的执行结果和准备状态返回给协调者。
- 提交阶段（Commit Phase）：
- 如果所有参与方的准备请求都成功，并且没有发生错误，协调者则发送提交请求给所有参与方。参与方接收到提交请求后，将正式提交事务，并释放相关资源。
如果在任何一个参与方的准备阶段出现错误、超时或者拒绝提交的情况，协调者将发送回滚请求给所有参与方，要求它们撤销之前的操作并回滚事务。
SEATA模式
Seata 是一个开源的分布式事务解决方案，它提供了多种模式来支持不同场景下的分布式事务处理。主要的 Seata 分布式事务模式包括 AT 模式（TCC 模式）、TCC 模式、SAGA 模式和XA 模式。
- AT 模式（TCC 模式）：
- AT 模式是 Seata 最基础的分布式事务模式，也称为 TCC（Try-Confirm-Cancel）模式。在 AT 模式中，事务分为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。应用程序需要实现这三个阶段的方法来保证事务的一致性。
- TCC 模式：
- TCC 模式和 AT 模式类似，也是基于 Try-Confirm-Cancel 的思想，但相比于 AT 模式更加灵活，允许业务逻辑更细粒度地控制事务的各个阶段。
- SAGA 模式：
- SAGA 模式是一种基于状态的分布式事务模式，在每个微服务内部处理自身的事务，并通过事件机制跨服务通信，从而实现全局事务的一致性。
- XA 模式：
- XA 模式是传统的两阶段提交协议，通过 XA 接口来协调多个数据库事务。Seata 通过支持 XA 模式来实现分布式事务的一致性。
Seata是强一致性事务吗
一般使用的是SEATA的AT模式；而AT模式是每个分支事务独立提交事务；所以是非强一致性事务。
柔性事务与刚性事务的区别
柔性事务满足BASE理论（基本可用，最终一致）
Basically Available基本可用
Soft-state 软状态/柔性事务
Eventual Consistency 最终一致性
刚性事务满足ACID理论
Atomic(原子性):要么都成功，要么都失败
Consistent(一致性):数据应该不被破坏
Isolate(隔离性):用户间操作不相混淆
Durable(持久性):永久保存
