领域战术核心：解密聚合根并发冲突防护与乐观锁（Version）设计规约

在领域驱动设计（DDD）的战术装配中，**聚合根（Aggregate Root）**是维护业务一致性边界的唯一物理入口。这意味着，聚合根内部所有实体与值对象的状态修改，必须由聚合根的方法统一把关。

然而，在高并发的互联网微服务环境下，一旦多个请求同时在不同的线程中加载了同一个聚合根，并分别执行修改（如：线程 A 扣减库存，线程 B 强行取消订单），就会发生严重的“丢失更新”或“状态机紊乱”。如果直接采用数据库排他锁（Pessimistic Lock），会导致系统的吞吐率腰斩。

为了确保高并发下聚合的不变性边界（Invariants）不被撕裂，DDD 推荐使用**基于版本号（Version）的乐观锁（Optimistic Locking）**作为核心防护手段。

本文将系统拆解并发冲突破坏聚合一致性的物理场景、悲观锁与乐观锁性能对比、以及在 JPA 中使用 @Version 守护聚合根的代码实践。

一、 核心防守策略对比：悲观锁 vs. 乐观锁

两种事务级并发控制手段在行锁锁定机制、吞吐率表现及数据库依赖度上存在根本差异：

二、 乐观锁防范并发更新丢失的流转拓扑

当两个高并发线程 A 和 B 几乎同时更新同一个账户聚合根的余额时，乐观锁的判定防护拓扑如下：

     [ 数据库表: ACCOUNT (id=1, balance=100.0, version=1) ]
                 │
      ┌──────────┴──────────┐
      ▼ 1. 线程 A 读取      ▼ 1. 线程 B 读取
   [ 内存中 A 的副本 ]     [ 内存中 B 的副本 ]  ──> 两个副本持有的 version 皆为 1
      │ (扣减 10 元)          │ (扣减 20 元)
      ▼                       ▼
   [ 2. 线程 A 优先持久化 ]  [ 2. 线程 B 稍后持久化 ]
      │                       │
      ▼                       ▼
   【 校验 version == 1 ? 】 【 校验 version == 1 ? 】
      │ (符合，允许写入)        │ (不符合！此时库中 version 已变更为 2)
      ▼                       ▼
   [ 3. SQL 写入成功 ]     [ 3. 拒绝写入，抛出 OptimisticLockingFailureException ]
   [ 库中 version 升至 2 ]    │
                              ▼
                           【 4. 捕获异常，自适应重试或提示用户“数据已被修改” 】

三、 代码实战：在 JPA 聚合根中声明并发冲突乐观锁

以下代码展示了如何在订单聚合根中声明版本控制，以及如何在仓储落盘时自动校验版本：

1. 领域层：包含版本控制的订单聚合根（Domain Layer）

package com.company.sales.domain.model;

import javax.persistence.*;
import java.util.Objects;

@Entity
@Table(name = "t_order")
public class SalesOrder {

    @Id
    private String orderId;

    private String status; // PLACED, PAID, CANCELLED

    // 核心乐观锁标志：由 JPA/Hibernate 框架进行静默维护，每次执行 update 时自增
    @Version
    private Long version;

    // 供 JPA 反射重建使用的无参构造
    protected SalesOrder() {}

    public SalesOrder(String orderId, String status) {
        this.orderId = Objects.requireNonNull(orderId);
        this.status = status;
    }

    /**
     * 业务方法：取消订单
     * 规约：必须在 PAID 状态下才能取消，保证状态机一致性
     */
    public void cancel() {
        if (!"PAID".equals(this.status)) {
            throw new IllegalStateException("未支付的订单无法执行取消动作！");
        }
        this.status = "CANCELLED";
    }

    public Long getVersion() { return version; }
}

2. 应用层：捕获并发冲突异常并自适应重试（Application Layer）

package com.company.sales.application.service;

import com.company.sales.domain.model.SalesOrder;
import com.company.sales.application.repository.OrderRepository; // 修正包路径
import org.springframework.orm.ObjectOptimisticLockingFailureException;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderApplicationService {

    private final OrderRepository orderRepository;

    public OrderApplicationService(OrderRepository repository) {
        this.orderRepository = repository;
    }

    /**
     * 取消订单的业务编排（含并发锁冲突退避重试）
     */
    @Transactional
    public void executeCancel(String orderId) {
        int maxRetry = 3; // 最大允许重试 3 次
        for (int i = 0; i < maxRetry; i++) {
            try {
                SalesOrder order = orderRepository.findById(orderId);
                order.cancel(); // 触发业务状态流转
                orderRepository.save(order); // 保存落盘，JPA 底层自动比对并升级 version
                return; // 成功则直接跳出
            } catch (ObjectOptimisticLockingFailureException e) {
                if (i == maxRetry - 1) {
                    throw new RuntimeException("系统繁忙，订单操作失败，请稍后重试！", e);
                }
                // 冲突退避：短暂随机等待后重新加载重试
                try { Thread.sleep(50 + (int)(Math.random() * 100)); } catch (InterruptedException ignored) {}
            }
        }
    }
}

四、 总结

基于版本号的乐观锁并发防线，是保障微服务聚合根在极限高并发下业务一致性边界的“安全阀”。

It 通过**在数据库更新阶段进行无锁的版本对比校验，免去了悲观行锁导致的物理挂起损耗，成倍释放了主调线程的响应吞吐力；并配合轻量级的退避重试设计，安全解决了临界并发冲突下的数据安全难题**。掌握这套乐观锁并发设计规约与异常退避重试代码，是进行海量高并发分布式系统研发、开发高韧性微服务聚合架构 of 核心看家本领！