【问题标题】:Jobs in the queue(pub-sub) distributed systems with dependencies?队列(发布-订阅)分布式系统中的作业具有依赖关系?
【发布时间】:2016-09-17 17:51:48
【问题描述】:

当队列中有作业(pub-sub)分布式系统时如何解决问题,并且它们之间存在依赖关系。

例如队列的当前状态:

j3 -> j2 -> j1
rear      front

j3依赖于j1的完成。

队列处理器正在使用这些作业并开始在分布式环境中处理它。

基于某种依赖解析机制,找出了j1j3之间的依赖关系。

现在,我不知道处理情况的最佳方法:

  • 我是否应该将j3 放回队列中,然后再次在 稍后阶段,以便 j1 到那时完成?
  • 我是否应该有一些其他机制 - 数据库来检查所有 j3依赖已经满足,然后处理j3

任何帮助将不胜感激。

谢谢!

【问题讨论】:

    标签: queue distributed-system


    【解决方案1】:

    让作业调度程序知道这些作业位于队列的最前面,但正在等待某些依赖项,这是最好的方法。这样,您可以在等待依赖项完成的同时完成其他工作,但仍尽可能按顺序处理它们。

    如果这样做相对便宜,如果队列长度相对较短并且依赖项很少,则将项目推回队列的开头是一个很好的解决方法。如果您推到后面的项目也是其他任务的依赖项,那么当它们到达前面时也需要将它们推到队列的后面(或者一次,但这太难了)。如果队列长度很长,您可能会看到意外的延迟。例如,如果队列长达一天,您最终可能要等待几天才能完成任务。如果该任务是依赖链的一部分,那么问题就会扩大。

    无论哪种方式,您都需要知道任务是否已排队/正在运行/已完成。你可以将这些信息存储在你最喜欢的数据库中,或者使用一些八卦协议或任何你喜欢的东西。如果同一作业执行两次不是正确性问题,则可以使用 AP 系统(在 CAP 意义上,具有最终一致性,例如 gossip 协议)。如果两次运行相同的任务会把事情搞得一团糟,你需要一些共识机制,比如一个单一的事实来源,比如你最喜欢的 sql 数据库或者 couchbase。

    【讨论】:

    • @AKK 有比 CAP 定理允许的 7 个更多的一致性模型,不过 :)
    • 您能否指出一些好的资源来阅读更多关于一致性模型的信息?谢谢!
    猜你喜欢
    • 2011-08-11
    • 1970-01-01
    • 2022-01-26
    • 1970-01-01
    • 2019-07-27
    • 2013-08-16
    • 1970-01-01
    • 2011-02-26
    • 2015-07-03
    相关资源
    最近更新 更多