【问题标题】:Storm max spout pending风暴最大喷口待定
【发布时间】:2014-08-16 06:39:17
【问题描述】:

这是一个关于 Storm 的 max spout pending 工作原理的问题。我目前有一个可以读取文件并为文件中的每一行发出一个元组的 spout(我知道 Storm 不是处理文件的最佳解决方案,但我没有选择解决这个问题)。

我将topology.max.spout.pending 设置为 50k 以限制有多少元组进入要处理的拓扑。但是,我看到这个数字在拓扑中没有任何影响。我每次都会看到文件中的所有记录。我的猜测是这可能是由于我在nextTuple() 方法中的一个循环,它发出文件中的所有记录。

我的问题是:当到达topology.max.spout.pending 时,Storm 是否会停止为 Spout 任务调用 nextTuple()?这是否意味着每次调用该方法时我应该只发出一个元组?

【问题讨论】:

    标签: real-time apache-storm


    【解决方案1】:

    没错! Storm 只能通过下一个命令限制您的 spout,因此如果您在收到第一个下一个命令时传输所有内容,Storm 就无法限制您的 spout。

    Storm 开发人员建议使用单个 next 命令发出单个元组。然后,Storm 框架将根据需要限制您的 spout 以满足“最大 spout 挂起”的要求。如果您要发出大量元组,您可以将您的发出批处理最多为最大 spout 待处理的十分之一,让 Storm 有机会进行节流。

    【讨论】:

    • 你能帮忙解决这个 stackoverflow.com/questions/34327617/... 吗? topology.max.spout.pending 50000000 有问题吗?
    【解决方案2】:

    Storm 拓扑有一个 max spout 挂起参数。最大值 拓扑的 spout 挂起值可以通过 拓扑中的“topology.max.spout.pending”设置 配置yaml文件。这个值限制了多少 元组可以在飞行中,即尚未被确认或失败,在 任何时间点的风暴拓扑。需要这个参数 来自Storm使用ZeroMQ调度的事实 从一个任务到另一个任务的元组。如果消费者方面 ZeroMQ 无法跟上元组速率,那么 ZeroMQ 队列开始建立。最终元组超时 喷出并重播到拓扑,从而增加了更多压力 在队列中。为了避免这种病态的失败案例,Storm 允许用户限制元组的数量 拓扑中的飞行。 此限制对每个 spout 任务生效 基础而不是拓扑级别。(source) 不可靠,即他们不会在他们的元组中发出消息 id,这 值没有影响。 Storm 用户不断面临的问题之一是 为这个待处理的最大喷口提出正确的值 范围。一个非常小的值很容易使拓扑饥饿,并且 足够大的值会使拓扑过载 导致失败和重放的元组数量。 用户必须经历几次拓扑迭代 具有不同最大喷口挂起值的部署以找到 最适合他们的价值。

    【讨论】:

    【解决方案3】:

    一种解决方案是在 nextTuple 方法之外构建输入队列,而在 nextTuple 中唯一要做的就是轮询队列并发出。如果您正在处理多个文件,您的 nextTuple 方法还应该检查轮询队列的结果是否为空,如果是,则自动重置正在填充您的队列的源文件。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-10-26
      • 2016-01-13
      • 2016-03-07
      • 2016-09-14
      • 1970-01-01
      相关资源
      最近更新 更多