Sidekiq Ruby on Rails背景工作的幂等设计

Question

Sidekiq recommends that all jobs be idempotent (able to run multiple times without being an issue) as it cannot guarantee a job will only be run one time.

I am having trouble understanding the best way to achieve that in certain cases. For example, say you have the following table:

User id email balance

The background job that is run simply adds some amount to their balance

def perform(user_id, balance_adjustment)
 user = User.find(user_id)
 user.balance += balance_adjustment
 user.save
end

If this job is run more than once their balance will be incorrect. What is best practice for something like this?

If I think about it a potential solution I can come up with is to create a record before scheduling the job that is something like

PendingBalanceAdjustment user_id balance_adjustment

When the job runs it will need to acquire a lock for this user so that there's no chance of a race condition between two workers and then will need to both update the balance and delete the record from pending balance adjustment before releasing the lock.

The job then looks something like this?

def perform(user_id, balance_adjustment_id)
  user = User.find(user_id)
  pba = PendingBalanceAdjustment.where(:balance_adjustment_id => balance_adjustment_id).take
  if pba.present?
    $redis.lock("#{user_id}/balance_adjustment") do
      user.balance += pba.balance_adjustment
      user.save
      pba.delete    
    end
  end
end

This seems to solve both

a) Race condition between two workers taking the job at the same time (though you'd think Sidekiq could guarantee this already?) b) A job being run multiple times after running successfully

Is this pattern a good solution?

Answer 1

You're on the right track; you want to use a database transaction, not a redis lock.

Answer 2

I think you're on the right track too but you're solution might be overkill since I don't have full knowledge of your application.

BUT, a simpler solution would simply be to have a flag on you User model like balance_updated:datetime . So, you could check that before updating.

As Mike mentions using a Transaction block should ensure it's thread safe.

In any case, to answer your question more generally... having an updated_ column is usually good enough to start with, and then if it gets complicated you can move this stuff to another model.