You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dolphinscheduler.apache.org by GitBox <gi...@apache.org> on 2021/06/10 13:33:19 UTC

[GitHub] [dolphinscheduler] lenboo commented on issue #4355: [Feature][Master+API+Scheduler] Propose for master refactor and scheduler module

lenboo commented on issue #4355:
URL: https://github.com/apache/dolphinscheduler/issues/4355#issuecomment-858627013


   
   关于Scheduler模块
   这确实是一个比较好的方案,可以很好地去掉zk锁,也可以减少数据库轮询次数,但是同时HA模式也是一个单点工作模式,当cmd的数量很大的情况下,分发cmd将会是瓶颈点,所以我们考虑实现真正的去中心化分布式设计来实现对cmd的处理。  
   
   我们考虑另外一种方案:
    hash分配cmd,去掉scheduler
    
   1. master启动时,根据zk和配置文件(槽位配置)计算出自己的槽位数,可能是多个 
   2. master根据自己的masterIds从db取cmd,根据cmdId除模取余,只取和槽位匹配的cmd 
   3. master上下线处理(master1=m1,master2=m2)
       1. m1上线,先计算出自己的masterIds,再开始取任务执行 
       2. m2上线,m1收到m2上线的消息以后,获取到一个全局锁,停止取cmd,重新计算自己的masterIds,同步给所有的master消息 
       3. 其他master收到消息以后,停止取cmd,重新计算自身masterIds,并将结果同步回复给m1 
       4. m1确定所有master都回复以后,再同步给所有的master一条消息,开始取新的cmd,释放全局锁 
       5. m1如果收到回复超时或者失败了,需要重新执行同步所有master的操作。 
       6. m3/m4如果收到已经处理过的消息,就跳过处理流程。 
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org