事件溯源（Event Sourcing）中余额一致性维护及Axon框架机制咨询

问题根源 #

你遇到的是典型的并发命令冲突：两个提现命令同时加载了同一账户的历史事件，回放后都得到初始余额100美元，各自判定余额充足并生成提现事件，最终导致余额透支。本质是事件溯源模式下，聚合根状态由事件回放生成，并发场景下如果没有版本控制或串行化机制，会出现"读-改-写"冲突。

Axon框架的内置解决方案 #

Axon针对这类问题提供了两种核心内置机制，无需手动实现复杂锁逻辑：

1. 聚合根版本控制（乐观锁） #

Axon会自动为每个聚合根维护版本号，版本号随事件发布递增。命令处理的核心流程如下：

• 处理命令时，Axon加载聚合根的当前版本及所有历史事件，回放生成当前状态。
• 命令处理完成并生成事件后，Axon会检查聚合根的当前版本是否与加载时的版本一致。
• 如果版本不一致（说明已有其他线程修改了该聚合根），则抛出ConcurrencyException，阻止事件保存。

具体实现示例：

@Aggregate
public class AccountAggregate {
    @AggregateIdentifier
    private String accountId;
    private BigDecimal balance;

    // Axon要求的默认构造函数
    public AccountAggregate() {}

    @CommandHandler
    public AccountAggregate(CreateAccountCommand cmd) {
        apply(new AccountCreatedEvent(cmd.getAccountId(), cmd.getInitialBalance()));
    }

    @CommandHandler
    public void handle(WithdrawMoneyCommand cmd) {
        // 基于回放后的状态判定余额是否充足
        if (balance.compareTo(cmd.getAmount()) >= 0) {
            apply(new MoneyWithdrawnEvent(accountId, cmd.getAmount()));
        } else {
            throw new InsufficientFundsException("余额不足");
        }
    }

    @EventSourcingHandler
    public void on(AccountCreatedEvent event) {
        this.accountId = event.getAccountId();
        this.balance = event.getInitialBalance();
    }

    @EventSourcingHandler
    public void on(MoneyWithdrawnEvent event) {
        this.balance = this.balance.subtract(event.getAmount());
    }
}

冲突处理流程：

1. 初始状态：账户版本0，余额100美元。
2. 第一笔提现命令加载版本0，处理成功，生成MoneyWithdrawnEvent，账户版本变为1。
3. 第二笔提现命令加载版本0，处理完成后准备保存事件时，Axon检测到当前版本已变为1，抛出ConcurrencyException。
4. 客户端捕获异常后重试命令，此时会重新加载最新事件（包括第一笔提现），回放后余额为0，直接拒绝提现。

2. 命令串行化（基于聚合根ID排序） #

如果希望从根源避免并发冲突，可以配置Axon的SequencingPolicy，让同一聚合根的命令串行执行。这样同一账户的所有命令会被放入同一队列，按顺序处理，不会出现同时加载同一聚合根的情况。

配置示例：

@Configuration
public class AxonConfig {
    @Bean
    public SequencingPolicy<? super CommandMessage<?>> aggregateSequencingPolicy() {
        // 基于聚合根ID对命令排序，同一ID的命令串行处理
        return new AggregateIdentifierSequencingPolicy();
    }
}

这种方式适合对一致性要求极高、不希望出现重试的场景，但会降低高并发下的吞吐量，需根据业务场景权衡。

关于锁机制的说明 #

事件溯源模式下不推荐使用传统的悲观锁（如数据库行锁），因为聚合根状态由事件回放生成，锁定事件集成本极高。Axon提供的乐观锁（版本控制）和命令串行化是更适配事件溯源的解决方案：

• 乐观锁：允许并发尝试，冲突时重试，吞吐量高，适合大多数高并发场景。
• 命令串行化：从根源避免冲突，一致性强，但吞吐量较低。

额外优化建议 #

• 客户端重试逻辑：捕获ConcurrencyException后，实现指数退避重试，避免频繁重试导致系统压力过大。
• 命令验证：在命令网关层先做基本参数校验，减少无效命令进入聚合根处理流程。

内容的提问来源于stack exchange，提问作者viktor nagla