dtm_master_running_flow
2016-08-03 15:29:56 0 举报dtm_master_running_flow是指DTM（分布式事务管理器）的主流程正在运行。DTM是阿里巴巴开源的一款分布式事务解决方案，用于解决分布式系统中的数据一致性问题。在分布式系统中，由于数据分布在多个节点上，因此需要进行协调和同步，以确保数据的一致性和完整性。DTM通过引入事务的概念，将多个操作封装成一个事务，并通过事务管理器来控制事务的提交和回滚。当DTM的主流程正在运行时，表示有一个或多个分布式事务正在被管理和执行。这些事务可能涉及到多个服务之间的数据交互和操作，DTM会负责协调这些操作的执行顺序和结果，以确保整个分布式系统的数据一致性。
作者其他创作
大纲/内容
Y
为新子进程在共享内存中登记
从Master继承过来的所有Pipe关掉所有Master侧Pipe关掉除自己外其它所有Worker侧Pipe
复用上一个子进程的Pipe
初始化accept锁调度队列
检查是否自己当前持有accept锁如果有，标记accept_held如果没有，timeout为1
end of while
N
将子进程在共享内存中注销
是否是有标记的子进程
框架调用update_new_worker函数传入新worker的通信socket，函数内部由文庆实现目的是将新worker update至可“开门接客”的最新状态
标记all_finished=1遍历epoll中所有fd
创建Nonblock主服务Socket开始Listen
是否有子进程退出
创建本进程epoll
Master
从服务Socket中accept出新的Client Socket并放入epoll，监听OUT事件
创建新一批子进程
将新client 和service_socket均放回epoll
处理Control指令
从master继承过来的所有socket pair关掉所有worker侧socket记录与master通信的socket为master_fd
遍历本次epoll返回的ready fd
如果有更新
accept_held?
如果accept_held，释放锁
为每个子进程创建一副Pipe
向当前所有非Control的子进程发送shutdown信号
阻塞epoll_wait，超时为timeout
为每个子进程在共享内存中登记
如果是client fd
将master中的配置中心逻辑抑制此处执行，总体思路不变每个循环，都将某一个active的action向前推进一个state
标记all_finished=0
处理待处理队列中的Socket和事件
初始化共享内存，作用：进程间抢锁、子进程登记
每个循环后的epoll事件集合
向与Control相连的管道write响应
对整个进程组Nonblock地waitpid
主循环while (! (g_gracefully_shutdown == 1) )
每次循环都试图更新含义是保证在进行本轮配置中心或者控制指令之前拿到最新最准确的worker信息
while 没有收到shutdown信号或all_finished=0
end of Master
清空子进程对应的Pipe两端
pselect 100ms
创建全部子进程Control除外，因为已存在
若为Worker且当前持有accept锁强制释放并移出调度队列
其他Socket
有标记的子进程说明是被Master显式有意杀死的无需重启
将每个Worker进程放入accept锁调度队列
每个Socket按照当前状态机继续流转
打开dtm.log日志文件
关闭控制Socket
这里会read/write db并真正执行控制操作这里逻辑，文庆实现需要依赖我提供的controller与master/worker的通信机制来完成控制行为
每个client fd按照各自状态机继续流转
read channel根据控制命令做处理
在channel上阻塞read来自Control的通知（Control会将每一个新生的Worker更新到最新状态）
Nonblock地读与Control进程相连的管道
进行wait_build和prepare_lock相关逻辑，暂不关心
while 没有收到shutdown或reload的signal
创建Nonblock控制Socket开始Listen
有Control指令？
如果收到shutdown信号，且accept_held将服务Socket从epoll中移除
将Socket和事件放入待处理队列
向所有子进程发送shutdown信号
子进程收到SIGUSR1或者SIGTERM就g_gracefully_shutdown=1不再有all_finished这个条件
读取配置文件更新内存中的配置信息
对退出子进程进行收割
绝大情况下，这个地方会simply超时，没有事件所以正常情况下，controller主要是执行的控制中心的逻辑
是否start所有子进程（Control指令之一）
收割所有退出的子进程
timeout设为check_timeout/1
为Client Socket？
将服务Socket和channel放入epoll，监听IN事件
读取共享内存，更新controller维护的alive worker信息
将自己侧Pipe标为channel
accept出client fd设置client fd为初始值
读入配置文件将全部MySQL、Redis连接信息存入内存
有超时的阻塞epoll_wait
标记当前所有非Control的子进程
是否shutdown所有子进程（Control指令之一）
初始化signal handlersSIGTERM - shutdownSIGWINCH - reloadSIGALRM - loadconf
创建全部子进程
如果是channel
如收到shutdown信号，断开
如果收到reload信号则exec新的binary进行重启
如果为Worker则放入accept锁调度队列
当前是否没有任何子进程Control除外
end of 遍历
如果超过server_timeout/1200无活动，断开
如果client fd状态机到终态，则不再放回epoll如果未到终态，则放回epoll如需要操作master，通过master fd
重启一个与退出子进程同类的子进程
向有标记的子进程（即老子进程）发送shutdown信号
关闭g_srv=service_socket
这里的状态机流转由文庆负责从现有worker状态机改进本质目的是将client的请求内容解读为控制行为，并依赖我提供的controller与master/worker的通信机制来完成控制行为
将g_srv=control_socket作为EPOLLIN放入本WORKER的epoll
对已存在子进程进行标记
如该Client连接上无active请求
如果是服务Socket且未收到shutdown信号
是否收到loadconf的signal
重新初始化日志关闭继承于Master的dtm.log的fd打开worker_process.log
执行accept调度让队列中的下一个Worker持有锁
如超过client_timeout/1200无活动，断开
如果是control_socket
0 条评论
下一页
