ruby-on-rails - Rails 4 并发问题

Question

我很难弄清楚我的模型表现如此的原因。

它有 2 个操作，取消和功能，当属性已经取消时，它不应该可以被推荐。

为了确保不会对已取消的属性执行功能，我使用 Redis-Mutex锁定属性的排他性并在 block 内进行适当的验证。这应该确保在一侧处理的记录不会同时在另一侧处理:

功能操作:

mutex = RedisMutex.new(record_to_feature, block: 30, sleep: 0.1)
if mutex.lock
    record_to_feature = record_to_feature.reload

    if record_to_feature.reload.active?
        record_to_feature.reload.update_attributes(featured: true)
    end
    mutex.unlock
end

取消操作:

mutex = RedisMutex.new(record_to_cancel, block: 30, sleep: 0.1)
if mutex.lock
    record_to_cancel = record_to_cancel.reload

    if !record_to_cancel.reload.featured?
        record_to_cancel.reload.update_attributes(active: false)
    end
    mutex.unlock
end

我想了解为什么有时(罕见)该属性会先被取消然后再被推荐 - 另一种方式:也可能会先被推荐然后取消，只是我没有检测到它。

请告诉我这是否是一个不好的方法，如果是，什么是解决此问题的好方法。

Answer 1

当 active == true 且featured == false 时，您可以调用功能操作。这会将 feature 设置为 true，因为 active == true。

然后您可以调用取消操作。由于featured == true，action 设置为 false。

现在，active == false，featured == true。

我画了一个简单的状态图来展示所有可能的状态变化。我没有包含无操作状态更改，例如，当 active 和featured 都为 false 时，您可以调用该功能或​​取消操作，但这不会执行任何操作。

箭头都代表调用 update_attributes 的路径。圆圈代表可以找到该记录的不同州。

可能不会出现活跃和特色都为假的状态 - 我不知道记录是如何构造的，因此为了完整性我将其包括在内。

很容易看出该记录如何被推荐，但尚未激活。

编辑:

这是更新后的状态图，其中修复并简化了 if 语句:

所以似乎不可能取消然后再添加。

我想到的一件事是，您没有检查 update_attributes 的返回值来查看更新是否成功。失败的更新能否解释观察到的行为？