分布式系统学习
分布式事务（Seata）
分布式事务概述
CAP理论
CAP理论由计算机科学家Eric Brewer提出，指出在分布式系统中，不可能同时满足以下三个特性：
- 一致性（Consistency） 所有节点在同一时间看到的数据完全相同（强一致性）。
- 可用性（Availability） 每个请求都能在合理时间内获得响应（非错误或超时）。
- 分区容错性（Partition Tolerance） 系统在发生网络分区（节点间通信中断）时仍能继续工作。
核心结论： 在分布式系统中，网络分区（P）是不可避免的（如网络故障），因此必须在一致性（C）和可用性（A）之间做出取舍：
- CP系统：牺牲可用性（A），保证强一致性（C）。例如：银行系统、ZooKeeper。
- AP系统：牺牲强一致性（C），保证高可用性（A）。例如：Cassandra、DynamoDB。
BASE理论
BASE理论是对CAP理论的补充，强调在无法实现强一致性的场景下，通过放宽一致性要求，实现高可用性和柔性架构。其核心思想是最终一致性。
- 基本可用（Basically Available） 系统在故障时仍能提供核心功能（如降级服务或限流）。
- 软状态（Soft State） 允许系统在不同节点间存在中间状态（数据可能暂时不一致）。
- 最终一致性（Eventually Consistent） 经过一段时间后，所有节点数据会达成一致（无需实时强一致）。
应用场景：
- 适合对一致性要求不高的场景，如社交网络、电商库存、日志系统等。
- 常见技术：异步复制、补偿事务（Saga模式）、版本冲突解决（如向量时钟）。
CAP与BASE的关系
| 维度 | CAP理论 | BASE理论 |
|---|---|---|
| 核心目标 | 理论层面的权衡模型 | 实践层面的设计指导 |
| 一致性要求 | 强一致性（C）或可用性（A） | 最终一致性（弱一致性） |
| 适用场景 | 强调严格取舍（CP或AP） | 在AP的基础上实现柔性一致性 |
Seata简介
2PC（二阶段提交协议）
2PC（Two-Phase Commit Protocol）是分布式系统中实现事务原子性的核心协议，确保跨多个节点的事务要么全部提交成功，要么全部回滚失败。其核心思想是将事务提交分为两个阶段：准备阶段和提交阶段。
1. 核心流程
| 阶段 | 描述 |
|---|---|
| 准备阶段 | 协调者询问所有参与者是否准备好提交事务，参与者锁定资源并返回确认。 |
| 提交阶段 | 协调者根据参与者反馈决定提交或回滚，并向所有参与者广播最终决定。 |
步骤详解：
- 协调者（Coordinator）向所有参与者（Participant）发送事务内容，并询问是否可提交（
Prepare请求）。 - 参与者执行事务操作（但不提交），记录Undo/Redo日志，锁定资源，并向协调者返回
Yes（准备就绪）或No（无法提交）。 -
协调者
收集所有参与者的响应：
- 若所有参与者返回
Yes，协调者发送Commit命令。 - 若有任一参与者返回
No或超时，协调者发送Rollback命令。
- 若所有参与者返回
- 参与者根据协调者指令执行提交或回滚，并释放资源锁，向协调者发送
Ack确认。 - 协调者收到所有参与者的
Ack后，结束事务。
2. 优点与缺点
| 优点 | 缺点 |
|---|---|
| ✅ 强一致性：保证所有节点数据一致。 | ❌ 同步阻塞：参与者在等待协调者指令时资源被锁定，影响并发性能。 |
| ✅ 简单易实现。 | ❌ 单点故障：协调者宕机会导致参与者长期阻塞或数据不一致。 |
❌ 数据不一致风险：若协调者发送Commit后部分参与者宕机，需人工干预恢复。 |
3. 2PC与CAP理论的关系
- 一致性（C）：2PC优先保证强一致性（所有节点提交或回滚）。
- 可用性（A）：在协调者或参与者故障时，系统可能不可用（如参与者等待超时）。
- 分区容错性（P）：网络分区可能导致事务阻塞或回滚。
结论： 2PC属于CP系统，牺牲可用性（A）以保障强一致性（C）和原子性，但无法完全解决分区容错性（P）带来的问题。
4. 适用场景与替代方案
| 适用场景 | 替代方案 |
|---|---|
| 传统数据库（如MySQL Cluster）。 | 3PC（三阶段提交）：引入超时机制和预提交阶段，降低阻塞风险。 |
| 小规模分布式系统。 | TCC（Try-Confirm-Cancel）：通过业务补偿实现柔性事务，适合高并发场景。 |
| 强一致性要求严格的场景。 | Saga模式：长事务拆分为多个本地事务，通过补偿操作回滚，牺牲强一致性。 |
5. 典型问题与解决方案
- 协调者单点故障
- 引入协调者集群（如ZooKeeper选举主备节点）。
- 记录事务日志，故障恢复后继续处理未完成事务。
- 参与者阻塞
- 设置超时机制，超时后自动回滚。
- 数据不一致
- 人工介入：根据日志修复未提交或未回滚的事务（如MySQL的XA事务恢复机制）。
基础架构
- TC(Transaction Co&rdinator)-事务协调者维护全局和分支事务的状态，驱动全局事务提交或回滚。
- TM(Transaction Manager)-事务管理器(发起者，同时也是RM的一种)定义全局事务的范围:开始全局事务、提交或回滚全局事务。
- RM(Resource Manager)-资源管理器(每个参与事务的微服务)管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata高可用配置
与nacos结合配置，使用nacos做注册中心和配置中心
事务分组问题：算是一个容错机制，防护机房断电问题，client和server端分组配置要一致
Seata-AT模式
AT模式是二阶段提交协议的演变
- 一阶段：拦截业务sql，记录undo和redo日志，生成锁
- 负责整体回滚和提交
