📚 课程目录第1章分布式事务概述

1. 分布式事务概述：CAP定理、BASE理论、分布式事务的挑战与场景

在单体架构中，数据库的本地事务（ACID）保证了强一致性。当系统拆分为多个微服务，每个服务拥有独立的数据库时，一次业务操作往往需要跨多个服务、多个数据库完成数据更新。此时，传统的本地事务无法跨越网络边界，分布式事务应运而生。

分布式事务的核心矛盾在于：网络是不可靠的，节点可能宕机，数据需要复制。这导致我们无法同时满足一致性、可用性和分区容错性这三个核心诉求。

CAP定理由Eric Brewer教授提出，是分布式系统的基石。它指出：一个分布式系统最多只能同时满足以下三项中的两项。

属性	全称	含义	类比
C	Consistency（一致性）	所有节点在同一时刻看到的数据完全相同。读操作总能返回最新的写操作结果。	银行转账后，查询余额必须立即反映扣减。
A	Availability（可用性）	每个请求都能获得一个（非错误的）响应，但不保证响应包含最新数据。	即使系统部分节点故障，用户依然能正常下单。
P	Partition Tolerance（分区容错性）	系统允许网络分区（节点间通信中断），仍能继续运行。	机房光纤被挖断，系统依然对外服务。

关键认知： 在分布式系统中，网络分区是必然发生的（P必须选）。因此，我们实际是在 CP（放弃可用性） 和 AP（放弃强一致性） 之间做选择。不存在所谓的CA系统，因为不选P意味着系统不是分布式的。

BASE理论是eBay架构师Dan Pritchett提出的，是对AP（可用性+分区容错性）方案的延伸。它放弃了强一致性，拥抱最终一致性。

缩写	全称	核心思想	Go实践体现
BA	Basically Available（基本可用）	系统允许出现降级，但核心功能必须可用。例如：秒杀时关闭评论功能。	使用 `hystrix-go` 或 `sentinel-golang` 做熔断降级。
S	Soft State（软状态）	允许系统存在中间状态，数据副本的同步存在延迟。	订单状态为“支付中”，而非立即变为“已支付”。
E	Eventually Consistent（最终一致性）	经过一段时间后，所有数据副本最终会达成一致。	通过消息队列 + 定时任务补偿实现。

    BASE vs ACID 对比：
    ACID 是“我等你，直到你完成”（强同步，高延迟）。
BASE 是“你先走，我随后跟上”（异步，高吞吐）。
BASE 是构建高可用、高并发微服务系统的理论基础。

在Go微服务架构中实现分布式事务，必须直面以下四个技术挑战：

网络不确定性（超时与重试）
- 调用远程服务可能超时，但服务端实际已成功处理。
- Go中常见的 context.WithTimeout 只能控制客户端等待，无法知晓服务端状态。
- 后果： 数据不一致，需要幂等设计。
节点故障与数据丢失
- 参与事务的某个微服务实例崩溃，导致事务日志丢失。
- Go中的goroutine panic若未recover，可能导致事务状态丢失。
- 后果： 部分提交，部分回滚，产生“脏数据”。
并发冲突与隔离性缺失
- 分布式事务缺乏全局锁，多个事务可能同时操作同一资源。
- Go的 sync.Mutex 只能解决单进程内的并发，跨服务需要分布式锁（如Redis Redlock）。
- 后果： 超卖、重复扣款。
事务协调者单点与状态持久化
- 协调者（如TCC中的Try阶段）若宕机，整个事务卡在中间状态。
- 协调者需要将事务状态写入数据库或etcd，保证可恢复。
- 后果： 事务悬挂，无法自动推进。

Go开发者避坑提示： 在Go中处理分布式事务时，不要依赖 time.Sleep 做重试。应使用指数退避算法（Exponential Backoff），并配合 context.Done() 实现优雅退出。否则，在服务重启或网络抖动时，重试风暴会瞬间打垮下游服务。

并非所有场景都需要分布式事务。以下表格帮助你在Go项目中快速判断：

场景类型	业务示例	推荐方案	一致性要求
强一致性场景	银行转账、库存扣减、账户余额变更	XA协议 / TCC模式	CP（强一致）
最终一致性场景	订单创建后发短信、积分累计、日志同步	本地消息表 / 事务消息（RocketMQ）	AP（最终一致）
可补偿场景	预订酒店后取消、退款流程、优惠券回收	SAGA模式	AP（最终一致 + 补偿）
非关键数据	用户浏览记录、埋点数据、缓存更新	异步MQ + 定时校对	弱一致