Storm短暂的Worker脑裂之旅

最新推荐文章于 2021-11-23 19:48:53 发布

原创

最新推荐文章于 2021-11-23 19:48:53 发布 · 2k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Storm #分布式 #hadoop #java #数据

博客详细分析了在Storm分布式环境中，由于Supervisor的Sync-Process线程导致的Worker启动超时和脑裂现象。当worker未能在超时时间内发送心跳，Supervisor会重复创建和启动新的worker，造成多个worker并发运行的问题。解决方案包括增加worker启动超时时间、启动后立即发送心跳以及在心跳时检查目录存在性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Storm中supervisor控制着worker的生命周期，负责worker的启停。
前端时间开发类似Storm中这样的一套系统时(worker和storm差别很大)脑裂的问题，supervisor负责启动一个worker，而最后上机器ps看到却有两个相同的worker，这两个相同的worker反复重启导致一堆奇怪的现象。

Supervisor与Worker

Storm中，supervisor主要有两个线程。如下图：

(图来自Twitter发的Storm论文)
10s运行一次的线程负责同步分配信息等。
3s一次的线程负责启动worker，创建worker需要的心跳目录等。
问题就出在3s一次的Sync-Process线程上。

Supervisor在Sync-Process中，大概会有一下动作：
1.杀掉超时或不合法的，删除心跳目录，注意，不合法的还包括workerId匹配不上的。
2.生成需要启动的worker的workerId。
3.创建心跳目录。
4.启动worker。
5.等worker首次心跳直到超时。
合理的剧本应该是启动好，supervisor等到worker心跳回来，正常运行。
但当时的情况时，worker在超时时间内没有心跳回来，不是因为worker异常退出了，而是worker还没来得及。
Supervisor在下次循环时，删除先前的心跳目录，再次生成新的workerId，启动一个worker，这时就有两个worker同时在运行。
worker1在worker2启动成功心跳了(强制创建了心跳目录)，但是此时worker1的Id已经被worker2的Id覆盖了，所以wor