dtm_master_worker_flow_rough
2016-04-28 16:24:58 0 举报dtm_master_worker_flow_rough是一种用于分布式数据处理的流程模型。在这个模型中，有一个主节点（Master）和多个工作节点（Worker）。主节点负责接收数据、分配任务和收集结果，而工作节点则负责执行具体的计算任务。这种模型可以有效地处理大量数据，提高计算效率。然而，它也有一些缺点，例如主节点的单点故障问题和数据同步问题。为了解决这些问题，人们提出了许多改进方案，如使用多个主节点和引入容错机制等。总之，dtm_master_worker_flow_rough是一种简单但有效的分布式数据处理模型，值得进一步研究和优化。
作者其他创作
大纲/内容
if(proc_info[i].graceful_shutdown == 1)如果是被master显式kill的
for 0 ~ g_srv-config-basic_config.max_threadsfork WORKER，修改共享内存来通知controlleradd_accept_worker
代码中通过声明控制action变量来注册控制action放入action_vector
Y
connect to global_config_db_node配置中心db测活
现在的signal handler没有区分角色难道每种角色收到同样信号的处理都一样吗？难道不应该是某些信号只能给worker发不能给master发以免无操作吗？
N
将proc_info中现有所有子进程均标记为graceful_shutdown=1，包括worker和func
创建g_srv
初始化signal handlers
创建g_srv-control_socket
有超时的阻塞epoll_wait
这里会read/write db并真正执行控制操作这里逻辑，文庆实现需要依赖我提供的controller与master/worker的通信机制来完成控制行为
g_gracefullly_child_shutdown = 1
绝大情况下，这个地方会simply超时，没有事件所以正常情况下，controller主要是执行的控制中心的逻辑
接到controller的update通知后Worker会进行相应的操作，由文庆负责开发应该可以复用worker主循环内收到控制命令后的操作
遍历本次epoll返回的ready fd
更新conf_modify_time读取config
禁止fork时不可以启动children
reload_dtm
g_no_forking == 0
主循环while (! (g_gracefully_shutdown == 1) )
每个循环后的epoll事件集合
for 0 ~ func_process[i] LOCKGUARD_PROCESSfork FUNC，修改共享内存来通知controller新增一个CONTROL_PROCESS角色与CONTROL_PROCESS通信的socket记为controller_fd
WIFSIGNALED(statloc)如果是被信号干掉的child，log一下继续
关闭g_srv=control_socket
g_gracefully_reload == 1
将g_srv=control_socket作为EPOLLIN放入本WORKER的epoll
当没有
遍历proc_info当前所有子进程如果仍有alive且shutdown=0的，则什么都不做，否则：
WORKER
accept出client fd设置client fd为初始值
读取共享内存，更新controller维护的alive worker信息
如果client fd状态机到终态，则不再放回epoll如果未到终态，则放回epoll
如果是g_srv-channel
更新conf_modify_time重新load_config_from_file
sleep 100ms
dtm_config_action_manager::manager_run每次执行要么当前cur_action的action要么新设action的preaction每次执行都read db获取每个action的执行phase每次执行都write db更新每个action的执行phase
channel的另一端因为child死掉而closeonexec但是我们这边的channel因为没有exec而没有close不需要显示close吗？会浪费fd，socketpair的系统资源也不会释放
框架调用update_new_worker函数传入新worker的通信socket，函数内部由文庆实现目的是将新worker update至可“开门接客”的最新状态
这里的状态机流转由文庆负责从现有worker状态机改进本质目的是将client的请求内容解读为控制行为，并依赖我提供的controller与master/worker的通信机制来完成控制行为
每个client fd按照各自状态机继续流转
将新client 和service_socket均放回epoll
创建g_srv-service_socket
不是worker也执行这个，好吗？
非阻塞read controller_fd获取需master执行的控制指令
accept_worker_manager由master来均匀调度哪个worker来持有accept锁
关闭g_srv=service_socket
将g_srv-channel作为EPOLLIN放入本WORKER的epoll
禁止fork时不可以loadconfloadconf也没有意义
如果是client fd
调用dtm_event_channel处理事件
CONTROLLER
读到控制指令后，设置全局变量如g_gracefully_loadconf、g_gracefullly_child_shutdown等新增变量g_no_forking，默认为0，只可被controller遥控改变
epid 0
遍历proc_info，向所有子进程均发送kill SIGTERMprocess_type = -1process_num = 0关闭所有socket pair
将master中的配置中心逻辑抑制此处执行，总体思路不变每个循环，都将某一个active的action向前推进一个state
如果是control_socket
直接read channel根据控制命令做处理
将g_srv=service_socket作为EPOLLIN放入本WORKER的epoll
初始化shm新增两块共享内存一块用于master通知controller哪些worker是存在的一块用于controller用于controller通知master不允许新fork worker
每循环read一次所以暂停、重启fork都是以循环为最小时间单位的
return
子进程收到SIGUSR1或者SIGTERM就g_gracefully_shutdown=1
直接write给各个worker的channel不再read
禁止fork时可以关闭children
这里不关闭channeldel accept和设置shutdown=0wait到了再做这些
如果client fd状态机到终态，则不再放回epoll如果未到终态，则放回epoll如需要操作master，通过master fd
在g_srv-channel上阻塞等待controller的update通知
子进程收到SIGUSR1或者SIGTERM就g_gracefully_shutdown=1不再有all_finished这个条件
while (g_gracefully_shutdown == 0)
将proc_info中现有所有子进程均kill SIGUSR1，包括worker和funcprocess_type = -1process_num = 0
遍历proc_info寻找是否dead child是哪个子进程
将proc_info中现有所有graceful_shutdown=0的子进程均kill SIGUSR1，均标记为graceful_shutdown=1
子进程收到SIGTERM就g_gracefully_shutdown=1
del_accept_worker(epid);
1 == g_gracefully_loadconf&& g_no_forking == 0
此时新老子进程均在proc_info里面均与master有channel均在accept队列里面
禁止fork时不wait因为如果dead children被wait掉了又没有重启，等fork开启后我们也不再知道哪些children曾经dead过需要重启
从master继承过来的所有socket pair关掉所有master侧socket记录自己对应的socket为g_srv-channel关掉其它所有worker侧socket
从master继承过来的所有socket pair关掉所有worker侧socket记录与master通信的socket为master_fd
这里不再wait所有worker真的退出吗？
如果有指令
初始化proc_info数组为该数组每个元素预创建socket pair（MAX_NUM_OF_PROCESS/200）
子进程收到SIGUSR1就g_gracefully_shutdown=1
init_accept_manager
dtm_unlock_mutexes(epid);
主循环while (! (g_gracefully_shutdown == 1 && all_finished == 1) )
reset proc_info[i]不会重启，不会close socket pair
end of while
如果是service_socket
每次循环都试图更新含义是保证在进行本轮配置中心或者控制指令之前拿到最新最准确的worker信息
如果有更新
g_gracefullly_child_start = 1&& g_no_forking == 0
0 条评论
下一页
为你推荐
查看更多
