Rails线程中数据库事务被回滚，是否应使用Sidekiq？

嗨，这个问题我之前做Rails项目的时候也踩过类似的坑，咱们一步步来理清楚：

为啥子线程里的数据库操作会被回滚？ #

Rails里ActiveRecord的数据库连接是线程本地绑定的，简单说就是每个线程都有自己独立的数据库连接池。当你在子线程里跑数据库操作时，容易碰到这几种情况：

• 子线程会单独从连接池拿新连接，但这个连接的事务和主线程完全不搭边。如果你的代码本身是在主线程的事务块里（比如控制器用了事务包裹，或者写了ActiveRecord::Base.transaction块），子线程的操作根本不会加入主线程的事务。但要是主线程的事务最后回滚了，你可能会误以为子线程的create也被回滚了——其实大概率是子线程的操作已经提交，但主线程事务回滚删了关联数据，或者因为数据库隔离级别，主线程查不到子线程刚提交的数据。
• 还有一种可能：如果主线程没等子线程跑完就结束了（比如请求提前响应），Rails会强制回收子线程的数据库连接，导致还没完成的事务直接被回滚。你虽然加了t.join让主线程等，但如果这段代码本身在一个更大的请求上下文里，还是可能踩坑。

怎么解决线程里的事务回滚问题？ #

你可以在子线程里显式管理数据库连接和事务，确保操作能正确提交：

t = Thread.new do
  # 显式获取并释放数据库连接
  ActiveRecord::Base.connection_pool.with_connection do
    # 用事务块包裹操作，保证原子性
    ActiveRecord::Base.transaction do
      Timeticket.create(item_id: 1, time: 10)
      # 没异常的话，事务会自动提交
    end
  end
  sleep 60
end
t.join
puts "thread ended"

with_connection能帮子线程正确拿连接、用完归还，显式事务块也能避免因为连接被强制回收导致的意外回滚。

要不要用Sidekiq这类异步任务工具？ #

必须推荐！而且是非常推荐的那种，原因有这几点：

• 省心力：Sidekiq自带完善的连接池管理，根本不用你手动处理线程连接的破事，从根源上避免这类事务回滚问题。
• 不拖垮Web服务：你代码里有sleep 60这种长时间操作，要是放在Web请求的线程里，会占着Web服务器的工作进程，导致其他请求进不来。Sidekiq跑在独立进程里，完全不影响Web服务的响应速度。
• 靠谱：Sidekiq有监控面板，能看任务跑没跑成；要是任务失败了（比如数据库突然挂了），还能自动重试，这手动写线程根本搞不定这么完善的机制。
• 代码好维护：把异步任务封装成独立的Job类，代码结构清晰，以后改需求或者查问题都方便。

给你举个Sidekiq的简单例子：

1. 先建个Job类：

# app/jobs/timeticket_create_job.rb
class TimeticketCreateJob
  include Sidekiq::Job

  def perform(item_id, time)
    Timeticket.create(item_id: item_id, time: time)
    sleep 60 # 这里睡多久都不影响Web请求
  end
end

2. 在业务代码里触发任务就行：

# 不用管线程，直接异步执行
TimeticketCreateJob.perform_async(1, 10)
puts "job queued"

这样既解决了事务回滚的问题，又让系统更稳定高效。

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