1. 课程导论

1.1 支付订单场景下的数据一致性困境

在分布式支付系统中，一笔订单的生命周期往往跨越多个微服务：订单服务、账户服务、库存服务、风控服务、清结算服务。每个服务通常拥有独立的数据库实例。当用户发起支付时，系统需要同时完成扣减账户余额、锁定库存、生成支付流水、更新订单状态等多个操作。这些操作必须满足 原子性 和 隔离性，否则就会出现资金损失或库存超卖。

传统单体数据库通过本地事务（ACID）保证一致性，但在微服务架构下，每个服务的数据被物理隔离，本地事务无法跨服务生效。此时，中间件层的事务隔离机制成为保障支付订单安全的关键防线。

1.2 中间件事务隔离：定义与职责

中间件事务隔离是指在数据库中间件（如 ShardingSphere、Vitess、PgBouncer 等）层面实现的事务控制能力。它位于应用层与数据库层之间，负责协调多个数据库节点上的事务行为，对外呈现统一的隔离级别。

中间件需要解决的核心问题包括：

• 分布式事务协议：如何协调多个数据库节点完成提交或回滚（XA、TCC、Saga）。
• 全局隔离级别：如何在跨库场景下实现 Read Committed、Repeatable Read 甚至 Serializable。
• 锁与冲突检测：如何避免分布式死锁，以及如何处理并发写入冲突。
• 故障恢复：当中间件或某个数据库节点宕机时，如何保证事务状态不丢失。

1.3 支付订单场景下的核心挑战

支付订单对事务隔离的要求远高于普通业务场景。以下是四个最关键的挑战：

1. 资金安全与幂等性：重复支付、超时重试、回调乱序都可能导致同一笔订单被多次扣款。中间件必须提供全局幂等控制，确保同一事务 ID 只执行一次。
2. 库存与余额的精确扣减：在高并发下，多个用户可能同时抢购同一商品。中间件需要保证“扣库存”和“生成订单”在同一个全局事务中，且隔离级别足够防止幻读。
3. 跨服务状态一致性：支付成功后，订单状态变为“已支付”，账户余额减少，物流系统开始发货。这三个操作必须全部成功或全部回滚，不允许出现“扣款成功但订单未更新”的情况。
4. 性能与隔离的平衡：严格的全局 Serializable 隔离会大幅降低吞吐量。中间件需要根据业务场景选择合适的事务模型（如 Saga 的最终一致性 vs. XA 的强一致性），并引入异步补偿机制。

1.4 课程目标与学习路径

本课程旨在帮助学员掌握在 PostgreSQL 生态下，通过中间件实现安全、高效的事务隔离，并能够将其应用于支付订单系统的实战开发。具体目标如下：

1.5 支付订单事务隔离架构总览

下图展示了在中间件层实现事务隔离的整体架构，以及支付订单请求的流转路径：

1.6 课程适用人群与前置知识

• 数据库管理员（DBA）：希望掌握中间件层的事务调优与故障排查。
• 后端开发工程师：负责支付、订单、库存等核心业务，需要设计安全的事务方案。
• 架构师：正在规划微服务数据一致性方案，需要对比不同中间件的隔离能力。
• 前置知识：熟悉 PostgreSQL 基本操作，了解 SQL 事务概念，有至少一种编程语言（Java/Go/Python）的使用经验。