【问题标题】:How to restore bolt state during failover如何在故障转移期间恢复 Bolt 状态
【发布时间】:2025-12-26 04:55:10
【问题描述】:

我试图弄清楚如何在故障转移期间恢复风暴螺栓实例的状态。我可以在外部(数据库或文件系统)保持状态,但是一旦重新启动螺栓实例,我需要指向该螺栓实例的特定状态以恢复它。 Bolt 的 prepare 方法接收上下文,记录在这里 http://nathanmarz.github.io/storm/doc/backtype/storm/task/TopologyContext.html

我不清楚的是——这个上下文中是否有任何部分可以唯一标识特定的螺栓实例,以便我可以理解指向哪个持久状态?在故障转移期间是否保留了该 ID?或者,我可以为故障转移期间保留的特定螺栓/实例设置任何变量/对象吗?任何帮助表示赞赏!

br 同胞

附: * 新手,请多多包涵...

【问题讨论】:

    标签: apache-storm


    【解决方案1】:

    您可能可以寻找Trident 它基本上是建立在storm 之上的抽象。文档说

    Trident 具有一流的抽象,用于读取和写入有状态的源。状态可以是拓扑内部的——例如,保存在内存中并由 HDFS 支持——或者外部存储在 Memcached 或 Cassandra 等数据库中

    如果发生任何故障转移,它会说

    Trident 以容错方式管理状态,因此在重试和失败时状态更新是幂等的。

    您可以查看文档以获得进一步的说明。

    【讨论】:

    • Tx 为那个 - 我会挖掘文档。乍一看,我似乎可以“通过事务”保持状态。只要使用三叉戟进行处理,这看起来不错。我想要做的是在一个螺栓中嵌入一个 3pp,并且 3pp 有它自己的状态持久性。我想在螺栓重新启动时恢复状态,所以我要做的就是记下状态的位置并在重新启动时收到通知。我将详细介绍 trident API 并再次发布。
    【解决方案2】:
    【解决方案3】:

    在原来的 Storm 中,spoutbolt 都是无状态的。 Storm 可以设法重新启动节点,但需要一些努力来恢复节点的状态。我能想到的解决方案有两种:

    1. 如果消息处理失败,Storm会从拓扑的ROOT重播,replay的逻辑必须由用户实现。所以在这种情况下,我想在消息中放入更多的状态信息(例如,一些外部状态存储的 ID 和此任务的 ID)。
    2. 或者您可以使用Trident。它可以为每个事务提供txid,简化存储过程。

    我可以接受第一个解决方案,因为我的应用不需要事务操作,而且我对原始 Storm 有更好的理解(Storm 生成的日志比 Trident 更简单)。

    【讨论】:

      【解决方案4】:

      您可以使用task ID

      任务 ID 在拓扑创建时分配,并且是静态的。如果任务终止/重新启动或被重新分配到其他地方,它仍将具有相同的 id。

      【讨论】: