如何确保模型始终使用事务和锁（在 Rails 中）？

Question

我注意到 Rails 可能与多个服务器存在并发问题，并希望强制我的模型始终锁定。 这在 Rails 中是否可能，类似于强制数据完整性的唯一约束？ 还是只需要仔细编程？

一号航站楼

irb(main):033:0* Vote.transaction do
irb(main):034:1* v = Vote.lock.first
irb(main):035:1> v.vote += 1
irb(main):036:1> sleep 60
irb(main):037:1> v.save
irb(main):038:1> end

二号航站楼，睡觉时

irb(main):240:0* Vote.transaction do
irb(main):241:1* v = Vote.first
irb(main):242:1> v.vote += 1
irb(main):243:1> v.save
irb(main):244:1> end

数据库启动

 select * from votes where id = 1;
 id | vote |         created_at         |         updated_at         
----+------+----------------------------+----------------------------
  1 |    0 | 2013-09-30 02:29:28.740377 | 2013-12-28 20:42:58.875973 

执行后

一号航站楼

irb(main):040:0> v.vote
=> 1

二号航站楼

irb(main):245:0> v.vote
=> 1

数据库端

select * from votes where id = 1;
 id | vote |         created_at         |         updated_at         
----+------+----------------------------+----------------------------
  1 |    1 | 2013-09-30 02:29:28.740377 | 2013-12-28 20:44:10.276601 

其他示例

http://rhnh.net/2010/06/30/acts-as-list-will-break-in-production

Answer 1

您是正确的，事务本身并不能防止许多常见的并发场景，增加计数器就是其中之一。 没有强制锁定的通用方法，您必须确保在代码中需要的任何地方使用它

对于简单的计数器递增场景，有两种机制可以很好地工作：

行锁定

只要您在代码中任何重要的地方都使用行锁定，它就会起作用。 知道重要的地方可能需要一些经验才能对 :/ 产生直觉。 如果像上面的代码一样，您有两个地方需要资源的并发保护，而您只锁定其中一个，则会出现并发问题。

你想使用with_lock形式； 这是一个事务和一个行级锁（表锁显然比行锁的可伸缩性差得多，尽管对于行数很少的表没有区别，因为 postgresql（不确定 mysql）无论如何都会使用表锁。这看起来像这样：

    v = Vote.first
    v.with_lock do
      v.vote +=1
      sleep 10
      v.save
    end

with_lock创建一个事务，锁定对象代表的行，并在一个步骤中重新加载对象属性，最大限度地减少代码中出现错误的机会。 然而，这并不一定能帮助您解决涉及多个对象交互的并发问题。 如果 a) 所有可能的交互都依赖于一个对象，并且您始终锁定该对象，并且 b) 其他对象每个只与该对象的一个​​实例交互，则它可以工作，例如锁定用户行并使用所有属于的对象执行操作（可能间接）该用户对象。

可序列化事务

另一种可能性是使用可序列化事务。 从 9.1 开始，Postgresql 具有“真正的”可序列化事务。 这比锁定行的性能要好得多（尽管在简单的计数器递增用例中不太可能重要）

了解可序列化事务为您提供什么的最佳方法是：如果您采用应用程序中所有(isolation: :serializable)事务的所有可能顺序，则保证您的应用程序运行时发生的情况始终与其中之一对应订单。 对于普通交易，不能保证这是真的。

但是，作为交换，您必须做的是处理事务失败时会发生什么，因为数据库无法保证它是可序列化的。 在计数器增量的情况下，我们需要做的就是retry ：

    begin
      Vote.transaction(isolation: :serializable) do
        v = Vote.first
        v.vote += 1
        sleep 10 # this is to simulate concurrency 
        v.save
      end
    rescue ActiveRecord::StatementInvalid => e
      sleep rand/100 # this is NECESSARY in scalable real-world code, 
                     # although the amount of sleep is something you can tune.
      retry
    end

注意重试前的随机睡眠。 这是必要的，因为失败的可序列化事务有一个非平凡的成本，所以如果我们不睡觉，多个进程争用同一个资源可能会淹没数据库。 在高度并发的应用程序中，您可能需要在每次重试时逐渐增加睡眠。 随机对于避免谐波死锁非常重要——如果所有进程睡眠相同的时间，它们可以相互进入节奏，它们都在睡眠中，系统空闲，然后它们都在同时，系统死锁导致除一个外的所有人再次进入睡眠状态。

当需要序列化的事务涉及与数据库以外的并发源交互时，您可能仍然需要使用行级锁来完成您需要的操作。 这方面的一个例子是，当状态机转换根据对数据库以外的其他内容（如第三方 API）的查询来确定要转换到的状态时。 在这种情况下，您需要在查询第三方 API 时使用状态机锁定表示对象的行。 您不能在可序列化事务中嵌套事务，因此您必须使用object.lock! 而不是with_lock 。

另一件要注意的事情是，在transaction(isolation: :serializable)外部获取的任何对象transaction(isolation: :serializable)都应该在事务内部使用之前调用它们reload 。

Answer 2

ActiveRecord 总是在事务中包装保存操作。

对于您的简单情况，最好只使用 SQL 更新，而不是在 Ruby 中执行逻辑然后保存。 这是一个添加模型方法来执行此操作的示例：

class Vote
  def vote!
    self.class.update_all("vote = vote + 1", {:id => id})
  end

此方法避免了在您的示例中锁定的需要。 如果您需要更一般的数据库锁定检查，请参阅 David 的建议。

Answer 3

您可以像这样在模型中执行以下操作

class Vote < ActiveRecord::Base

validate :handle_conflict, only: :update
attr_accessible :original_updated_at
attr_writer :original_updated_at

def original_updated_at
  @original_updated_at || updated_at 
end 

def handle_conflict
    #If we want to use this across multiple models
    #then extract this to module
    if @conflict || updated_at.to_f> original_updated_at.to_f
      @conflict = true
      @original_updated_at = nil
      #If two updates are made at the same time a validation error
      #is displayed and the fields with
      errors.add :base, 'This record changed while you were editing'
      changes.each do |attribute, values|
        errors.add attribute, "was #{values.first}"
      end
    end
  end
end 

original_updated_at是设置的虚拟属性。 更新记录时会触发handle_conflict 。 检查数据库中的updated_at属性是否晚于隐藏的属性（在您的页面上定义）。 顺便说一句，您应该在您的app/view/votes/_form.html.erb定义以下app/view/votes/_form.html.erb

<%= f.hidden_field :original_updated_at %>

如果存在冲突，则引发验证错误。

如果您使用的是 Rails 4，您将没有 attr_accessible，并且需要将:original_updated_at添加到您的控制器中的vote_params方法中。

希望这能带来一些启示。

Answer 4

对于简单的 +1

Vote.increment_counter :vote, Vote.first.id

因为表名和字段都使用了vote ，所以这两个是如何使用的

TableName.increment_counter :field_name, id_of_the_row