Axon Framework：如何回滚domain_event_entry表中的事件？

你遇到的这个问题，本质是Axon中事件存储的持久化时机和外部EventHandler的事务边界不匹配导致的。默认情况下，Axon在聚合的CommandHandler处理完成后，会立即将事件持久化到domain_event_entry表（这个操作属于CommandHandler事务的一部分），然后才会把事件分发给外部的EventHandler。这意味着，当你的TemplateCreatedEventHandler抛出异常回滚自己的事务时，事件已经被永久写入事件存储了，自然会出现“事件存在但实体表为空”的不一致情况。

下面针对不同业务场景，给出几种可行的解决方案：

方案1：让EventHandler与CommandHandler共享同一个事务（同步处理） #

如果你的业务场景允许同步处理事件（即Command的处理必须等待EventHandler完成才返回），可以将事件处理器配置为SubscribingEventProcessor（默认是异步的TrackingEventProcessor），这样EventHandler会和CommandHandler在同一个线程、同一个事务中执行。一旦EventHandler抛出异常，整个事务会回滚，包括事件存储的写入。

配置与代码调整： #

1. 在application.properties中指定事件处理器模式：

# 全局配置所有处理器为同步模式
axon.eventhandling.processors.default.mode=subscribing

# 或者针对特定处理器配置（更灵活）
axon.eventhandling.processors.template-event-processor.mode=subscribing

2. 在你的EventHandler类上指定处理器分组：

@Service
@ProcessingGroup("template-event-processor")
public class TemplateCreatedEventHandler {
    private static final transient Logger logger = LoggerFactory.getLogger(TemplateCreatedEventHandler.class);
    @Autowired
    private TemplateRepository templateRepository;

    @Transactional
    @EventHandler
    public void on(TemplateCreatedEvent event) {
        templateRepository.save(new TemplateQueryEntity(event));
        logger.info("EventHandler - TemplateCreatedEvent");
        throw new RuntimeException();
    }
}

注意事项： #

• 这种方式会增加Command的响应时间，因为要等待EventHandler执行完成，适合处理逻辑简单、耗时短的场景。
• 避免在EventHandler中加入长时间阻塞操作，否则会严重影响Command的吞吐量。

方案2：使用补偿事件（最终一致性） #

如果同步处理不符合你的业务需求（比如需要高吞吐量、EventHandler有耗时操作），那么更符合Axon事件驱动理念的方式是使用补偿事件来修复不一致。事件溯源的核心是“事件是已发生的事实，不能被删除”，所以我们不应该尝试回滚事件存储，而是通过追加补偿事件来抵消之前事件的影响。

实现步骤： #

1. 定义补偿事件TemplateCreationFailedEvent：

public class TemplateCreationFailedEvent {
    private String templateId;
    private String failureReason;

    // 构造器、getter方法
    public TemplateCreationFailedEvent(String templateId, String failureReason) {
        this.templateId = templateId;
        this.failureReason = failureReason;
    }

    // getter...
}

2. 修改EventHandler，捕获异常并发布补偿事件：

@Service
public class TemplateCreatedEventHandler {
    private static final transient Logger logger = LoggerFactory.getLogger(TemplateCreatedEventHandler.class);
    @Autowired
    private TemplateRepository templateRepository;
    @Autowired
    private EventGateway eventGateway;

    @Transactional
    @EventHandler
    public void on(TemplateCreatedEvent event) {
        try {
            templateRepository.save(new TemplateQueryEntity(event));
            logger.info("EventHandler - TemplateCreatedEvent");
            throw new RuntimeException("模拟持久化失败");
        } catch (RuntimeException e) {
            logger.error("创建TemplateQueryEntity失败，templateId: {}", event.getTemplateId(), e);
            // 发布补偿事件，通知系统处理不一致
            eventGateway.publish(new TemplateCreationFailedEvent(event.getTemplateId(), e.getMessage()));
            throw e; // 继续抛出异常，确保当前事务回滚
        }
    }
}

3. 编写补偿事件的处理器，清理不一致状态：

@Service
public class TemplateCreationFailedEventHandler {
    @Autowired
    private TemplateRepository templateRepository;

    @Transactional
    @EventHandler
    public void on(TemplateCreationFailedEvent event) {
        // 删除可能残留的实体（如果事务回滚不彻底，或者有其他关联资源需要清理）
        templateRepository.deleteById(event.getTemplateId());
        logger.info("已补偿：删除失败的TemplateQueryEntity，templateId: {}", event.getTemplateId());
    }
}

注意事项： #

• 这种方式是最终一致性的，需要业务接受短暂的不一致状态。
• 补偿逻辑需要保证幂等性，比如多次收到同一个补偿事件时，不会重复执行清理操作。

方案3：调整事件提交时机（不推荐） #

如果你一定要让事件只在所有EventHandler处理成功后才持久化，可以通过Axon的UnitOfWork来控制事件的提交时机，但这种方式违背了事件溯源的核心思想（事件是已发生的事实，应该立即持久化），可能会导致事件丢失等问题，仅作为特殊场景下的备选方案。

不推荐的原因： #

这种方式会破坏Axon的架构设计，增加系统复杂度，而且很难处理分布式场景下的异常情况，因此不建议在生产环境使用。

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