2、PostgreSQL事务基础：ACID特性、事务隔离级别、BEGIN/COMMIT/ROLLBACK
在认证授权平台中，用户注册、角色分配、权限同步等操作往往涉及多个数据表的联合更新。任何一个步骤失败都可能导致数据不一致——例如用户已创建但角色未绑定，或令牌已签发但审计日志缺失。PostgreSQL 的事务机制正是解决这类问题的核心保障。本章从 ACID 特性、隔离级别和基本控制语句三个维度，建立事务控制的底层认知。
2.1 ACID 特性：事务的四大基石
事务（Transaction）是数据库执行逻辑的最小工作单元。PostgreSQL 严格遵循 ACID 原则，确保并发环境下数据的可靠性与一致性。
| 特性 | 全称 | 含义 | 认证授权场景示例 |
|---|---|---|---|
| A | 原子性 (Atomicity) | 事务内的所有操作要么全部成功提交，要么全部回滚撤销 | 创建用户 + 分配默认角色必须同时成功或同时失败 |
| C | 一致性 (Consistency) | 事务执行前后，数据库始终满足所有约束、规则和业务逻辑 | 用户表与角色关联表的外键约束不能因事务中断而破坏 |
| I | 隔离性 (Isolation) | 并发执行的事务之间互不干扰，每个事务都感觉自己是唯一运行的 | 两个管理员同时修改同一用户的角色时，不会产生脏读或更新丢失 |
| D | 持久性 (Durability) | 已提交的事务结果永久保存，即使系统崩溃也不会丢失 | 令牌撤销记录一旦提交，即使数据库重启也必须生效 |
关键认知： ACID 不是独立存在的四个特性，而是层层递进的关系——原子性保证操作完整，一致性保证数据合法，隔离性保证并发安全，持久性保证结果不丢。在认证授权平台中，一致性是最容易被忽视但后果最严重的特性。
2.2 事务隔离级别：控制并发冲突的粒度
SQL 标准定义了四种事务隔离级别，PostgreSQL 全部支持。隔离级别越高，数据一致性越强，但并发性能越低。认证授权平台通常需要在 读已提交 和 可重复读 之间权衡。
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | PostgreSQL 默认 | 适用场景 |
|---|---|---|---|---|---|
| 读未提交 (Read Uncommitted) | 可能 | 可能 | 可能 | 否（实际等同于读已提交） | 不推荐使用 |
| 读已提交 (Read Committed) | 不可能 | 可能 | 可能 | 是 | 常规查询、令牌验证、日志写入 |
| 可重复读 (Repeatable Read) | 不可能 | 不可能 | 可能（PG 可避免） | 否 | 角色权限快照、批量授权检查 |
| 可串行化 (Serializable) | 不可能 | 不可能 | 不可能 | 否 | 敏感资源分配、并发极高的权限变更 |
PostgreSQL 特殊行为： 在可重复读级别下，PostgreSQL 通过快照技术（Snapshot）实际上也避免了幻读。因此，PG 的可重复读比标准 SQL 定义更严格，适合认证授权平台中需要“一次读取、多次使用”的场景。
2.3 事务控制语句：BEGIN / COMMIT / ROLLBACK
PostgreSQL 使用三条核心语句显式控制事务边界。在认证授权平台的异步任务编排中，每条语句都对应着明确的业务语义。
- BEGIN：显式开启一个新事务。在 PL/pgSQL 函数或存储过程中，也可以用
START TRANSACTION替代。 - COMMIT：提交当前事务，使所有修改永久生效。提交后，其他事务才能看到本次变更。
- ROLLBACK：回滚当前事务，撤销所有未提交的修改。数据库恢复到事务开始前的状态。
-- 认证授权平台典型事务示例：创建用户并分配角色
BEGIN;
-- 步骤1：插入用户记录
INSERT INTO users (username, email, status)
VALUES ('zhangsan', 'zhangsan@example.com', 'active');
-- 步骤2：获取新用户ID（假设使用序列）
-- 实际开发中建议使用 RETURNING 子句
INSERT INTO user_roles (user_id, role_id, granted_at)
VALUES (currval('users_id_seq'), 2, NOW());
-- 步骤3：写入审计日志
INSERT INTO audit_log (action, target, operator, occurred_at)
VALUES ('CREATE_USER', 'zhangsan', 'admin', NOW());
-- 所有操作成功，提交事务
COMMIT;
-- 如果任何一步失败，则执行 ROLLBACK 回滚
常见陷阱： 在异步任务编排中，事务边界必须与任务边界对齐。不要在同一个事务中混合同步数据库操作和外部 API 调用（如发送邮件、调用第三方认证服务），否则外部调用失败会导致数据库操作也被回滚，造成业务状态丢失。
2.4 事务隔离级别与并发冲突示意图
下图展示了不同隔离级别下，事务 A 和事务 B 并发操作同一行数据时的可见性差异。深色节点表示事务执行的操作，箭头表示数据流向。
2.5 事务与异步任务编排的关联
在认证授权平台的异步任务编排中，事务控制需要额外关注以下三点：
- 事务边界与任务边界对齐：每个异步任务单元（如“创建用户并发送欢迎邮件”）应包含完整的事务，避免跨任务的事务悬挂。
- 隔离级别选择策略：读取密集型任务（如令牌验证）使用默认的读已提交；涉及权限快照的任务（如批量角色同步）升级为可重复读。
- 回滚补偿机制：当异步任务编排中的某个子任务失败时，不能简单依赖数据库 ROLLBACK，因为其他子任务可能已经提交。需要设计业务层面的补偿事务（Compensating Transaction）。
实践建议： 在认证授权平台中，将事务控制与异步消息队列（如 RabbitMQ、Kafka）结合使用时，务必遵循“先提交数据库事务，再发送消息”的顺序。如果先发消息再提交事务，消费者可能读到尚未持久化的数据，导致脏读或状态不一致。