如何在after_rollback模型回调中保存记录？事务回滚场景咨询

核心结论 #

直接在after_rollback回调里保存模型完全不可行——此时当前数据库连接仍处于原事务的上下文（即便主事务已触发回滚），新的保存操作会被后续的事务清理逻辑一并回滚。消息队列/事件发布确实是这类场景下最可靠的通用方案，但还有几个特定场景下的可选思路：

可选方案 #

1. 使用独立数据库连接 #

在回调中创建全新的数据库连接，脱离当前事务上下文执行保存操作。以Rails为例：

after_rollback :log_event_force

def log_event_force
  ActiveRecord::Base.connected_to(role: :writing) do
    EventLog.create!(action: "rollback_triggered", details: "事务因XX错误回滚")
  end
end

注意：这种方式会绕过当前连接池与事务隔离规则，需确保数据库配置支持多连接，同时要处理好连接释放，避免资源泄漏。

2. 原生SQL直接执行（跳过ActiveRecord事务） #

如果只是简单的记录插入，可直接用原生SQL绕过ActiveRecord的事务管理：

after_rollback :log_event_raw

def log_event_raw
  sql = "INSERT INTO event_logs (action, details, created_at) VALUES ('rollback_triggered', '事务因XX错误回滚', NOW())"
  ActiveRecord::Base.connection.execute(sql)
end

但这种方式需要自行防范SQL注入风险，且无法复用模型的验证、回调等逻辑，仅适合极简场景。

3. 消息队列/事件发布（推荐） #

你提到的消息队列方案是最稳妥的选择：在after_rollback中发布事件到队列（如Sidekiq、RabbitMQ），由队列的独立进程执行数据库写入。队列进程的数据库连接与原事务完全隔离，不受回滚影响，同时实现异步解耦，避免阻塞主业务流程。

关于嵌套事务的补充 #

嵌套事务在多数数据库（如MySQL）中是基于保存点实现的“伪嵌套”，无法做到真正的部分提交——外层事务回滚时，内层保存点的变更也会被一并回滚，这也是它不适合你的核心原因。

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