3. 常见幂等方案一：数据库唯一键约束（唯一索引、联合唯一索引）实现防重，适用场景与局限性分析

数据库唯一键约束是支付系统中最基础、最可靠的幂等实现手段。其核心思想是：利用数据库层面的唯一性约束，保证同一笔业务请求在表中只能存在一条记录。当重复请求到达时，数据库会因违反唯一约束而拒绝插入，从而避免重复处理。

3.1 实现原理与核心流程

唯一键约束防重的关键在于将业务幂等键映射为数据库唯一索引。每次请求处理前，先尝试插入一条包含幂等键的记录；插入成功则继续业务逻辑，插入失败（唯一键冲突）则判定为重复请求，直接返回已有结果。

核心公式： 幂等键（Idempotent Key） → 数据库唯一索引 → 插入成功 = 首次请求，插入失败 = 重复请求
设计要点： 幂等键必须能够唯一标识一笔业务请求，通常由业务类型、请求方标识、业务流水号等字段组合生成。支付系统中常见的幂等键包括：商户订单号、支付流水号、退款请求号等。
唯一键约束幂等防重流程 业务请求到达 提取幂等键（订单号+业务类型） INSERT INTO 幂等表 (幂等键, 状态) 插入成功？ 首次请求 执行业务逻辑 重复请求 返回已有结果 更新状态为“成功” DuplicateKeyException 捕获

3.2 两种实现方式对比

实现方式 定义 适用场景 示例
单字段唯一索引 在单个字段上创建 UNIQUE 索引 幂等键由单一业务字段构成，如全局唯一的支付流水号 UNIQUE INDEX idx_pay_id (pay_transaction_id)
联合唯一索引 在多个字段上创建复合 UNIQUE 索引 幂等键由多个业务字段组合而成，如商户ID + 商户订单号 UNIQUE INDEX idx_merchant_order (merchant_id, merchant_order_no)

3.3 适用场景

  • 支付下单防重： 同一商户订单号在短时间内被重复提交时，通过联合唯一索引（商户ID + 商户订单号）拦截重复请求。
  • 退款请求防重： 退款请求号作为唯一键，防止退款指令被重复执行导致多次扣款。
  • 转账交易防重： 交易流水号作为唯一索引，确保同一笔转账只被处理一次。
  • 回调通知防重： 支付网关的回调通知可能重复发送，使用通知ID作为唯一键避免重复更新订单状态。
  • 批量导入/对账： 对账文件中的记录通过唯一键去重，防止重复入账。

3.4 局限性分析

重要提示： 唯一键约束虽然简单可靠，但在高并发、分布式场景下存在明显的性能瓶颈和架构限制，需要结合其他方案综合设计。
局限性 详细说明 影响程度
数据库写压力 每次请求都需要执行一次 INSERT 操作，高并发下数据库写入成为瓶颈。即使重复请求也会产生一次写操作（虽然失败），增加数据库负载。 高
分布式事务问题 幂等表与业务表通常不在同一数据库，需要分布式事务保证一致性。引入 XA 或 TCC 会增加系统复杂度。 高
主键冲突异常处理 DuplicateKeyException 是数据库层面的异常，应用层需要精确捕获并区分“真正重复”与“其他异常”，否则可能误判。 中
索引维护成本 唯一索引在数据量大时会影响写入性能，B+树索引的维护需要额外的磁盘 I/O 和内存开销。 中
跨库/跨表场景 当幂等键需要跨多个数据库或分片时，无法使用单库的唯一索引，需要引入全局唯一 ID 生成器或分布式锁。 高
无法处理“空响应”场景 如果首次请求因网络超时导致客户端未收到响应，但服务端已成功插入幂等记录，客户端重试时会被拦截，但无法返回业务结果。 中

3.5 最佳实践与避坑指南

推荐实践：
  1. 幂等表与业务表分离： 创建独立的幂等记录表（idempotent_record），避免与业务表耦合，便于独立扩展和清理。
  2. 设置合理的 TTL： 幂等记录不需要永久保留，建议设置过期时间（如 24 小时），通过定时任务或数据库事件清理过期数据。
  3. 使用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE： 在 MySQL 中，可以使用 INSERT IGNORE 避免异常抛出，或使用 ON DUPLICATE KEY UPDATE 更新状态。
  4. 幂等键生成规则： 建议采用“业务类型 + 业务标识 + 时间戳”的组合方式，确保全局唯一性。
-- 幂等记录表设计示例（MySQL）
CREATE TABLE idempotent_record (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    idempotent_key VARCHAR(128) NOT NULL COMMENT '幂等键',
    business_type VARCHAR(32) NOT NULL COMMENT '业务类型',
    status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-处理中，1-成功，2-失败',
    result_json TEXT COMMENT '业务结果JSON',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE INDEX uk_idempotent_key (idempotent_key),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='幂等记录表';

-- 使用 INSERT IGNORE 避免异常
INSERT IGNORE INTO idempotent_record (idempotent_key, business_type, status)
VALUES ('MERCHANT_ORDER_20231001_123456', 'PAYMENT', 0);

-- 如果影响行数为 1，表示首次插入，继续业务逻辑
-- 如果影响行数为 0，表示重复请求，查询已有结果返回
避坑提醒：
  • 不要依赖数据库主键自增做幂等： 主键自增只能保证记录唯一，无法表达业务幂等语义。
  • 注意字符集和排序规则： 幂等键字段建议使用 utf8mb4_bin 或 utf8mb4_unicode_ci，避免因大小写或字符集差异导致唯一约束失效。
  • 避免在事务中先查询再插入： 先 SELECT 再 INSERT 存在竞态条件，无法在高并发下保证幂等，必须直接使用唯一索引约束。
  • 监控唯一键冲突率： 如果冲突率过高（如超过 5%），说明上游存在大量重复请求，需要排查调用方逻辑或增加前置去重。

3.6 小结

数据库唯一键约束是支付系统幂等设计的基石方案，具有实现简单、数据一致性高、无需额外中间件等优点。但它并非万能：在高并发写入、分布式事务、跨库场景下存在明显短板。实际生产环境中，通常将唯一键约束作为兜底方案，与前置缓存去重、分布式锁、状态机等方案组合使用，形成多层幂等防护体系。

← 上一章 📖 返回目录 下一章 →