1. 课程导论：支付订单领域聚合建模与幂等防重整体架构概览
在分布式支付系统中，幂等性是保障资金安全和数据一致性的核心防线。本课程将系统讲解如何通过领域驱动设计（DDD）的聚合建模思想，结合 Redis 高性能防重策略，构建一套健壮的支付订单幂等处理体系。本章作为导论，首先勾勒整体架构蓝图，明确各模块的职责与协作关系。
1.1 支付订单领域的核心挑战
支付场景天然面临重复请求的风险：网络超时重试、用户多次点击、消息队列重复投递等。若缺乏有效的幂等防重机制，可能导致同一笔订单被多次扣款、多次发货，造成严重资损。下表总结了支付订单领域常见的重复请求来源及其影响：
| 重复请求来源 | 典型场景 | 潜在后果 |
|---|---|---|
| 客户端重试 | 用户支付时网络闪断，前端自动重试 | 同一订单生成多笔支付单 |
| 服务端超时重试 | 支付网关超时，上游服务发起重试 | 重复扣款，余额多扣 |
| 消息队列重复消费 | MQ 未开启去重，消费者收到多条相同消息 | 重复更新订单状态，数据不一致 |
| 第三方回调重复 | 银行/支付宝重复发送支付结果通知 | 订单状态被多次修改，对账不平 |
1.2 领域驱动设计视角下的聚合建模
DDD 强调通过聚合（Aggregate）来封装业务不变性和一致性边界。在支付订单领域，我们将 PaymentOrder 作为核心聚合根，围绕它组织以下实体与值对象：
- 聚合根：PaymentOrder — 唯一标识一笔支付交易，持有订单状态、金额、支付方式等核心属性。
- 实体：PaymentTransaction — 记录每次支付尝试的流水，包含请求来源、渠道、结果等。
- 值对象：Money — 金额值对象，封装币种与数值，保证金额计算的无副作用。
- 值对象：PaymentResult — 支付结果值对象，包含渠道返回码、支付时间等。
聚合建模的关键在于：所有对订单状态的变更必须通过聚合根，从而在领域层统一实施幂等校验，避免业务规则分散在应用层或基础设施层。
核心原则：聚合边界内的数据一致性由领域模型保证，幂等防重是聚合根行为的一部分，而非外部拦截的补丁。
1.3 幂等防重整体架构概览
本课程设计的幂等防重架构采用分层协作模式，从请求入口到领域模型形成完整的防重链路。整体架构分为四层：
- 接入层（API Gateway） — 基于请求唯一键（如幂等 Token）进行第一层拦截，快速过滤明显重复的请求。
- 应用层（Application Service） — 协调 Redis 防重组件，在进入领域层前完成幂等令牌的获取与验证。
- 领域层（Domain Layer） — 聚合根内部维护业务幂等状态，确保同一业务请求只执行一次有效变更。
- 基础设施层（Infrastructure） — 提供 Redis 分布式锁、防重表、消息去重等通用能力。
下图展示了各层在幂等防重流程中的协作关系：
1.4 Redis 在防重策略中的核心角色
Redis 凭借其高性能和原子操作特性，成为实现分布式防重的首选基础设施。本课程将深入讲解以下 Redis 防重模式：
| 防重模式 | 核心原理 | 适用场景 |
|---|---|---|
| SET NX + 过期时间 | 利用 Redis 的 SET NX 命令实现分布式锁，请求成功则获得执行权 | 短时间内的重复请求拦截，如支付提交 |
| Redis 防重表 | 以业务唯一键为 Key，存储请求状态，通过原子操作判断是否已处理 | 需要记录处理结果的场景，如回调通知 |
| Lua 脚本原子校验 | 将校验与更新逻辑封装在 Lua 脚本中，保证原子性 | 复杂防重逻辑，如先查状态再更新 |
| 布隆过滤器 | 基于布隆过滤器快速判断请求是否可能重复，减少 Redis 访问 | 高并发场景下的第一层过滤 |
1.5 课程知识体系与学习路径
本课程共 30 章，按以下模块组织：
- 基础篇（第 1-5 章）：幂等概念、DDD 聚合建模基础、Redis 防重原理解析。
- 建模篇（第 6-12 章）：支付订单聚合建模实战、实体与值对象设计、领域事件驱动。
- 集成篇（第 13-20 章）：Redis 防重策略实现、分布式锁优化、Lua 脚本原子性保障。
- 进阶篇（第 21-25 章）：高并发压测、防重降级、多级缓存与布隆过滤器。
- 实战篇（第 26-30 章）：完整支付订单系统实现、单元测试、生产部署与监控。
学习建议：建议先掌握 DDD 的基本概念和 Redis 常用命令，再跟随课程逐步搭建完整的幂等防重体系。每章末尾的代码示例和思考题将帮助你巩固所学。