dtm_master_worker_flow_rough
2016-04-28 16:24:58 0 举报dtm_master_worker_flow_rough是一种数据处理流程，它采用了主从模式和工作流的方式。在这种模式下，有一个主节点负责协调和管理整个流程，而多个从节点则负责执行具体的任务。这种模式可以提高数据处理的效率和可靠性，同时也能够更好地适应大规模数据处理的需求。在实际应用中，dtm_master_worker_flow_rough可以用于各种场景，如数据清洗、数据分析、机器学习等。总之，dtm_master_worker_flow_rough是一种高效、可靠的数据处理流程，值得进一步研究和开发。
作者其他创作
大纲/内容
Y
g_gracefully_reload == 1
for 0 ~ g_srv-config-basic_config.max_threadsfork WORKER记录channeladd_accept_worker
if(proc_info[i].graceful_shutdown == 1)如果是被master显式kill的
del_accept_worker(epid);
1 == g_gracefully_loadconf
此时新老子进程均在proc_info里面均与master有channel均在accept队列里面
代码中通过声明控制action变量来注册控制action放入action_vector
遍历proc_info当前所有子进程如果仍有alive且shutdown=0的，则什么都不做，否则：
connect to global_config_db_node配置中心db测活
现在的signal handler没有区分角色难道每种角色收到同样信号的处理都一样吗？难道不应该是某些信号只能给worker发不能给master发以免无操作吗？
N
将proc_info中现有所有子进程均标记为graceful_shutdown=1，包括worker和func
epid 0
创建g_srv
遍历proc_info，向所有子进程均发送kill SIGTERMprocess_type = -1process_num = 0
初始化signal handlers
初始化proc_info数组包括每个channel
子进程收到SIGUSR1就g_gracefully_shutdown=1
初始化shm
更新conf_modify_time重新load_config_from_file
return
g_gracefullly_child_shutdown = 1
更新conf_modify_time读取config
init_accept_manager
dtm_unlock_mutexes(epid);
sleep 100ms
dtm_config_action_manager::manager_run每次执行要么当前cur_action的action要么新设action的preaction每次执行都read db获取每个action的执行phase每次执行都write db更新每个action的执行phase
这里不关闭channeldel accept和设置shutdown=0wait到了再做这些
reload_dtm
channel的另一端因为child死掉而closeonexec但是我们这边的channel因为没有exec而没有close不需要显示close吗？
reset proc_info[i]不会重启，不会close channel直接置为-1
for 0 ~ func_process[i] LOCKGUARD_PROCESSfork FUNC记录channel
end of while
while (g_gracefully_shutdown == 0)
将proc_info中现有所有子进程均kill SIGUSR1，包括worker和funcprocess_type = -1process_num = 0
遍历proc_info寻找是否dead child是哪个子进程
WIFSIGNALED(statloc)如果是被信号干掉的child，log一下继续
创建g_srv-service_socket
将proc_info中现有所有graceful_shutdown=0的子进程均kill SIGUSR1，均标记为graceful_shutdown=1
不是worker也执行这个，好吗？
accept_worker_manager由master来均匀调度哪个worker来持有accept锁
g_gracefullly_child_start = 1
0 条评论
下一页
为你推荐
查看更多
