状态机在特定时间转换

时间：2011-10-24 15:34:33

标签： ruby-on-rails queue state-machine

简化示例：

我有一个待办事项。它可以是未来，当前或晚期，具体取决于它的时间。

  Time       State
  8:00 am    Future
  9:00 am    Current
  10:00 am   Late

因此，在这个例子中，待办事项是从上午9点到早上10点的“当前”。

最初，我考虑过为“current_at”和“late_at”添加字段，然后使用实例方法返回状态。我可以使用now > current and now < late查询所有“当前”待办事项。

简而言之，我每次都会计算状态，或者使用SQL来提取我需要的状态集。

如果我想使用状态机，我会有一组状态，并将该状态名称存储在待办事项上。但是，如何在每个待办事项的特定时间触发州之间的过渡？

  • 每分钟运行一次cron作业以拉出状态但超过转换时间并更新它
  • 使用后台处理在将来的适当时间对转换作业进行排队，因此在上面的示例中，我将有两个作业：“过渡到当前上午9点”和“过渡到晚上10点”可能会有防止被删除的待办事项的逻辑和“如果完成则不要迟到”等等。

在尝试在特定时间处理大量状态转换时，是否有人有管理这些选项的经验？

感觉就像状态机，我只是不确定管理所有这些转换的最佳方式。

回复后更新：

  • 是的，我需要查询“当前”或“未来”待办事项
  • 是的，我需要触发关于状态变化的通知（“你的待办事项没有完成”）

因此，我希望更多的是类似状态机的想法，以便我可以封装过渡。

6 个答案:

答案 0 :(得分：5)

我设计并维护了几个管理大量这些小型状态机的系统。 （某些系统，最高100K /天，约100K /分钟）

我发现你明确地摆弄的状态越多，就越有可能在某个地方打破。或者换句话说，你推断的状态越多，解决方案就越健壮。

话虽如此，你必须保持一些状态。但尽量保持尽可能小。

此外，将状态机逻辑保持在一个位置使系统更健壮，更易于维护。也就是说，不要将状态机逻辑放在代码和数据库中。我更喜欢代码中的逻辑。

首选解决方案。 （简单的图片最好）。

对于你的例子，我会有一个非常简单的表：

task_id, current_at, current_duration, is_done, is_deleted, description...

和根据与now和current_at相关的current_duration推断状态。这非常有效。确保在current_at上对表进行索引/分区。

处理转换变更的逻辑

当您需要在转换更改时触发事件时，情况会有所不同。

将您的表格更改为：

task_id, current_at, current_duration, state, locked_by, locked_until, description...

将您的索引保持在current_at，并根据需要在state上添加一个。你现在正在破坏状态，所以由于并发或失败，事情会变得更脆弱，所以我们必须使用locked_by和locked_until来支持它以获得乐观锁定，我会描述如下。

我认为你的程序在处理过程中会失败 - 即使只是为了部署。

您需要一种机制将任务从一种状态转换为另一种状态。为了简化讨论，我会关注自己从FUTURE转到CURRENT，但无论过渡如何，逻辑都是一样的。

如果您的数据集足够大，您不断轮询数据库以发现发现需要转换的任务（当然，当没有任何事情可做时，线性或指数退避）;否则你使用或你最喜欢的调度程序是cron还是ruby-based，如果你订阅了Java / Scala / C＃，那就是Quartz。

选择所有需要从FUTURE移动到CURRENT 并且的条目当前未被锁定。

（的更新：）

-- move from pending to current
select task_id
  from tasks
 where now >= current_at
   and (locked_until is null OR locked_until < now)
   and state == 'PENDING'
   and current_at >= (now - 3 days)         -- optimization
 limit :LIMIT                               -- optimization

将所有这些task_id扔进可靠的队列中。或者，如果必须，只需在脚本中处理它们。

当您开始处理某个项目时，必须先使用我们的乐观锁定方案将其锁定：

update tasks
   set locked_by = :worker_id     -- unique identifier for host + process + thread
     , locked_until = now + 5 minutes -- however this looks in your SQL langage
 where task_id = :task_id         -- you can lock multiple tasks here if necessary
   and (locked_until is null OR locked_until < now) -- only if it's not locked!

现在，如果你真的更新了记录，你就拥有了锁。 您现在可以启动特殊的转换逻辑。（掌声。这就是让您与所有其他任务管理器不同的原因，对吗？）

当成功时，更新任务状态，确保仍然使用乐观锁定：

update tasks
   set state = :new_state
     , locked_until = null -- explicitly release the lock (an optimization, really)
 where task_id = :task_id
   and locked_by = :worker_id -- make sure we still own the lock
                              -- no-one really cares if we overstep our time-bounds

多线程/流程优化

只有当多个线程或进程批量更新任务时（例如在cron作业中或轮询数据库），才能执行此操作！问题是他们每个人都会从数据库中获得类似的结果，然后争先恐后地锁定每一行。这是低效的，因为它会减慢数据库的速度，并且因为你的线程基本上什么都不做，只会减慢其他线程。

因此，请为查询返回的结果数量添加限制并遵循此算法：

results = database.tasks_to_move_to_current_state :limit => BATCH_SIZE
while !results.empty
    results.shuffle! # make sure we're not in lock step with another worker
    contention_count = 0
    results.each do |task_id|
        if database.lock_task :task_id => task_id
           on_transition_to_current task_id
        else
           contention_count += 1
        end
        break if contention_count > MAX_CONTENTION_COUNT # too much contention!
    done
    results = database.tasks_to_move_to_current_state :limit => BATCH_SIZE
end

使用BATCH_SIZE和MAX_CONTENTION_COUNT，直到程序超快。

<强>更新

乐观锁定允许多个并行处理器。

通过锁定超时（通过locked_until字段），它允许在处理转换时失败。如果处理器发生故障，另一个处理器能够在超时后接收任务（上述代码中为5分钟）。因此，重要的是a）只在你要处理任务时锁定任务;和b）锁定任务执行任务需要多长时间加上一个慷慨的余地。

locked_by字段主要用于调试目的，（这个进程/机器是什么？）如果数据库驱动程序返回更新的行数，则只有locked_until字段就足够了，但是如果您一次更新一行，则仅。

答案 1 :(得分：4)

在特定时间管理所有这些转换似乎很棘手。也许您可以使用像DelayedJob这样的东西来安排转换，这样每分钟就不需要一个cron作业，从故障中恢复会更加自动化？

否则 - 如果这是Ruby，是否使用Enumerable一个选项？

像这样（在未经测试的伪代码中，使用简单的方法）

ToDo类

def state
  if to_do.future?
    return "Future"
  elsif to_do.current?
    return "Current"
  elsif to_do.late?
    return "Late"
  else 
    return "must not have been important"
  end
end

def future?
    Time.now.hour <= 8
end

def current?
    Time.now.hour == 9
end

def late?
    Time.now.hour >= 10
end

def self.find_current_to_dos
    self.find(:all, :conditions => " 1=1 /* or whatever */ ").select(&:state == 'Current')
end

答案 2 :(得分：3)

适用于中等大小数据集的一个简单解决方案是使用SQL数据库。每个待办事项记录应具有“state_id”，“current_at”和“late_at”字段。你可以省略“future_at”，除非你真的有四种状态。

这允许三种状态：

  1. 未来：当现在＆lt; current_at
  2. 当前：当current_at＆lt; = 现在＆lt; late_at
  3. 迟到：当late_at＆lt; = 现在

    4. 将状态存储为state_id（可选地将外键设置为名为“states”的查找表，其中1: Future，2: Current，3: Late）基本上存储de-标准化数据，可以避免在很少更改时重新计算状态。

    如果您实际上并未根据状态（例如... WHERE state_id = 1）查询待办事项记录或在状态发生变化时触发一些副作用（例如发送电子邮件），则可能您不需要管理状态。如果你只是向用户显示一个待办事项列表并指出哪些是迟到的，那么最便宜的实现甚至可能是计算客户端。为了回答，我假设您需要管理状态。

    您有一些更新state_id的选项。我假设您正在执行约束current_at < late_at。

    • 最简单的是更新每条记录：UPDATE todos SET state_id = CASE WHEN late_at <= NOW() THEN 3 WHEN current_at <= NOW() THEN 2 ELSE 1 END;。

    • 您可能会通过（在一个交易中）UPDATE todos SET state_id = 3 WHERE state_id <> 3 AND late_at <= NOW()，UPDATE todos SET state_id = 2 WHERE state_id <> 2 AND NOW() < late_at AND current_at <= NOW()，UPDATE todos SET state_id = 1 WHERE state_id <> 1 AND NOW() < current_at之类的内容获得更好的效果。这样可以避免检索不需要更新的行，但是你需要索引“late_at”和“future_at”（你可以尝试索引“state_id”，见下面的注释）。您可以根据需要经常运行这三个更新。

    • 上面的略微变化是首先获取记录的ID，因此您可以对已更改状态的待办事项执行某些操作。这看起来像SELECT id FROM todos WHERE state_id <> 3 AND late_at <= NOW() FOR UPDATE。然后，您应该执行UPDATE todos SET state_id = 3 WHERE id IN (:ids)之类的更新。现在你仍然有ID可以在以后做一些事情（例如通过电子邮件发送通知“20个任务已经过期”）。

    • 为每个待办事项安排或排队更新作业（例如，在上午10点将此一个更新为“当前”并在晚上11点将其更新为“晚期”）将导致批次预定作业，至少todos数量的两倍，性能不佳 - 每个预定的作业只更新一条记录。

    • 您可以安排批量更新，例如UPDATE state_id = 2 WHERE ID IN (1,2,3,4,5,...)，您已经预先计算了在某个特定时间附近将变为当前的待办事项ID列表。由于几个原因，这在实践中可能不会很好。在您安排更新后，其中一些todo的current_at和late_at字段可能会发生变化。

    注意：通过索引“state_id”可能无法获得太多收益，因为它只会将数据集分为三组。这可能不足以让查询规划人员考虑在SELECT * FROM todos WHERE state_id = 1等查询中使用它。

    你没有讨论的这个问题的密钥是完成的待办事项会发生什么？如果您将它们保留在此待办事项表中，则该表将无限增长，并且您的性能将随着时间的推移而降低。解决方案是将数据分区为两个单独的表（如“completed_todos”和“pending_todos”）。然后，您可以在实际需要时使用UNION连接两个表。

答案 3 :(得分：2)

国家机器是由某种东西驱动的。用户交互或流中的最后一个输入，对吧？在这种情况下，时间驱动状态机。我认为一个cron工作是正确的。这将是驱动机器的时钟。

对于它的价值是非常困难的，在两列上设置一个有效的索引，你必须做这样的范围。

现在＆gt;当前＆amp;＆amp;现在＆lt;迟到很难以高效的方式在数据库中表示为任务的属性

ID |标题| future_time |的current_time | late_time

1 |你好| 8：00am | 9：00am | 10:00 am

答案 4 :(得分：1)

永远不要试图强迫模式进入问题。事情是相反的。所以，直接找到一个好的解决方案。

这是一个想法:(我理解你的是）

使用持久警报和一个受监控的进程来“消耗”它们。其次，查询它们。

这将允许您：

  1. 保持简单
  2. 保持便宜。其次它也会让你在精神上更多 新鲜的做其他事。
  3. 仅将所有逻辑保留在代码中（应该如此）。

    4. 我强调要使用某种监视程序监视该进程，以确保及时发送这些警报（或者，在最坏的情况下，在发生崩溃之后会有一些延迟或类似事件）。

    请注意：保留这些警报的事实可以让您做到这两点：

    1. 使您的系统保持弹性（更具容错能力）和
    2. 使您能够查询未来和当前项目（通过查询最符合您需求的警报时间范围）

答案 5 :(得分：0)

根据我的经验，当你有一个外部进程对某些东西起作用，并用它的状态更新数据库时，SQL中的状态机最有用。例如，我们有一个上传和转换视频的流程。我们使用数据库随时跟踪视频发生的情况，以及接下来会发生什么。

在您的情况下，我认为您可以（并且应该）使用SQL来解决您的问题而不必担心使用状态机：

制作一个todo_states表：

todo_id  todo_state_id    datetime  notified
1        1 (future)       8:00      0
1        2 (current)      9:00      0
1        3 (late)         10:00     0

您的SQL查询，其中包含所有实际工作：

SELECT todo_id, MAX(todo_state_id) AS todo_state_id 
FROM todo_states
WHERE time < NOW()
GROUP BY todo_id

当前活动状态始终是您选择的状态。如果您只想通知用户一次，请插入带有notify = 0的原始状态，并在第一次选择时将其碰撞。

一旦任务“完成”，您可以将另一个状态插入到todo_states表中，或者只是删除与任务相关联的所有状态，并在待办事项中引发“完成”标志，或者任何最有用的状态你的情况。

不要忘记清理过时状态。

相关问题
最新问题