【译】用悲观锁处理竞争

最近正在开发的一个Rails应用,由于后台任务操作的AR对象存在竞争引发了issue,在本文中,我将使用悲观锁(pessimistic lock)来解决此问题。

举个例子

首先,假设一个如下有feature的Rails应用:

  1. 管理员能看到客户列表
  2. 管理员能访问客户主页以及给客户一条短信
  3. 管理员一天对一个客户至多只能发送一条短信

为了让情况尽可能简单,假设一个Client模型和一条属性last_sms_sent_on ,以及一个类(被用于controller或者Sidekiq任务):

class ClientSMSSender
  def self.perform(client, message)
    client.transaction do 
      if client.last_sms_sent_on.blank? || !client.last_sms_sent_on.today?
        client.last_sms_sent_on = Date.today
        client.save
        SMSGateway.send(client.phone_number, message)
      end
    end
  end
end
分析竞争问题

假设这时候出现其他情况,SMSGateway.send出现卡顿并且持续时间30秒以上。同时,其他管理员发起了一个新的请求并且发送SMS给客户。由于竞争机制,我们将在同一天发送多条短信给客户。

具体情况如下:

  1. 管理员A发起一个请求(Request A),发送一条SMS给客户
  2. 客户端几天还没有接收到任何短信
  3. Request A由于外部因素卡住
  4. 管理员B此时也发起一个请求并且发送一条短信给客户
  5. 客户今天还没有收到任何短信(因为A卡主了)
  6. Request B同样由于外部原因卡主
  7. Request A完成并且更新了client.last_sms_sent_on
  8. Request B 还是坚持之前的客户端状态
  9. Request B 完成,并且发送短信和更新状态
解决方案

为了解决此问题,我们可以使用with_lock方法(ActiveRecord::Locking::Pessimistic)
代码如下:

class ClientSMSSender
  def self.perform(client, message)
    client.with_lock do
      if client.last_sms_send_on.blank? || !client.last_sms_sent_on.today?
        client.last_sms_sent_on = Date.today
        client.save
        SMSGateway.send(client.phone_number, message)
      end
    end
  end
end

with_lock:

  1. 开启一个数据库事务
  2. 重载数据记录(为了获取最新的记录)
  3. 对此条记录开启一个互斥锁

当使用with_lock之后:

  1. 管理员A发起一个请求(Request A),发送一条短信给客户
  2. Request A 在数据库端锁住了这条记录
  3. 客户端几天还没有接收到任何短信
  4. Request A由于外部因素卡住
  5. 管理员B此时也发起一个请求并且发送一条短信给客户
  6. 由于此条记录被Request A锁住,所以Request B一直挂起,直到数据库释放这条记录。
  7. Request A完成并且更新了client.last_sms_sent_on
  8. 数据库释放(release)了这条记录
  9. Request B (正在挂起,等待数据库)开始执行。
  10. Request B 锁住这条记录
  11. Request B 重载数据(为了获得最新数据)
  12. 客户已经接受了一条数据
  13. Request B 完成,没有发送短信

如果你对此还有疑惑,可以在Rails console中测试:

  1. 开启2个Rails console
  2. 在第1个console中:
u = User.first
u.with_lock do 
  u.email = "[email protected]"
  u.save
  sleep 40
end

在第二个console中:

  u = User.first
  u.email = "[email protected]"
  u.save

第二个console中的u.save一直挂住直到第一个console完成了整个进程。此外最好不要将整个app锁住,不然会遇到意想不到的麻烦。

总结

with_lock方法十分方便,但是尽量少使用。多出使用此方法虽然可以带来好的逻辑持续性,但随之而来的是巨大的性能消耗。

http://blog.thefrontiergroup.com.au/2015/11/handling-race-conditions-rails-pessimistic-locking/

你可能感兴趣的:(【译】用悲观锁处理竞争)