【译】用悲观锁处理竞争

最近正在开发的一个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 = "test@thefrontiergroup.com.au"
  u.save
  sleep 40
end

在第二个console中：

  u = User.first
  u.email = "test2@thefrontiergroup.com.au"
  u.save

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

总结

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

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