Erlang pool management -- RabbitMQ worker_pool

在RabbitMQ中,pool 是以worker_pool 的形式存在的, 其主要用途之一是对Mnesia transaction 的操作. 而在RabbitMQ 中, pool 中的worker 数量是固定不变的, 是和虚拟机的schedulers 相关.这次会首先分别分析设计worker_pool 功能的三个module, 然后分析worker_pool 和 worker_pool_worker module 之间的调度关系.

worker_pool_sup module

worker_pool_sup module 是RabbitMQ pool(以下简称为rpool)的supervisor 进程,用来start worker_pool gen_server 进程和若干数量的worker_pool_worker gen_server 进程, 其中worker_pool_worker gen_server 进程的数量和虚拟机的schedulers 相关.

start_link() ->
    start_link(erlang:system_info(schedulers)).

start_link(WCount) ->
    supervisor:start_link({local, ?SERVER}, ?MODULE, [WCount]).

%%----------------------------------------------------------------------------

init([WCount]) ->
    {ok, {{one_for_one, 10, 10},
          [{worker_pool, {worker_pool, start_link, []}, transient,
            16#ffffffff, worker, [worker_pool]} |
           [{N, {worker_pool_worker, start_link, []}, transient, 16#ffffffff,
             worker, [worker_pool_worker]} || N <- lists:seq(1, WCount)]]}}.

L2 处调用了erlang:system_info/1 函数以获取当前虚拟机使用的schedulers 数目. 在L13 处, 添加了和schedulers 数目等量的worker_pool_worker gen_server 进程.

这里这样设计的主要目的是为了和Mnesia transaction 操作相匹配. (多说一句, Mnesia transaction 操作是由gen_server 进程控制, 默认是异步操作, Mnesia transaction 的操作频率过大的话, 容易导致mnesia_tm 进程的消息队列overload, 所以, 控制Mnesia transaction 并发调用数量, 可以避免mnesia_tm message len overload 引发的系统性能下降)

worker_pool_worker module

worker_pool_worker module 定义了rpool 的工作进程, 使用gen_server2 behaviour.

worker_pool_worker module 主要定义了:

1, next_job_from/2

主要用于 worker_pool_worker 进程 monitor 用户进程, 并将worker_pool_worker 进程的state 置为{from, CPid(用户进程), MRef(monitor 结果)}, 等待用户进程任务的submit. 

当收到用户进程 'DOWN' 的message 时, 若当前state 为该用户进程, 则将worker_pool_worker 进程的状态置为dile, state 置为undefined .

此函数的调用者为worker_pool 进程, 第一个参数为worker_pool_worker 进程Pid, 第二个参数为用户进程Pid .

2, submit/3

主要用户进程想worker_pool_worker 进程submit 任务, 然后根据当前worker_pool_worker 进程的state 来决定是执行用户进程提交的Fun 函数, 还是重置进程的state 信息, 等待下一次next_job_from message.

handle_call({submit, Fun, CPid, ProcessModel}, From, undefined) ->
    {noreply, {job, CPid, From, Fun, ProcessModel}, hibernate};

handle_call({submit, Fun, CPid, ProcessModel}, From, {from, CPid, MRef}) ->
    erlang:demonitor(MRef),
    gen_server2:reply(From, run(Fun, ProcessModel)),
    ok = worker_pool:idle(self()),
    {noreply, undefined, hibernate};

在上面handle_call callback 处理submit tag 的message 中, state 信息为{from, CPid, MRef}, 即执行用户提交的Fun 任务, 若state 信息为'undefined', 就重置state 信息,并等待next_job_from message :

handle_cast({next_job_from, CPid}, {job, CPid, From, Fun, ProcessModel}) ->
    gen_server2:reply(From, run(Fun, ProcessModel)),
    ok = worker_pool:idle(self()),
    {noreply, undefined, hibernate};

执行Fun 任务.

两个不同的处理逻辑的最后,都会调用worker_pool module 的idle 函数, 告诉worker_pool 进程自己已经idle .(以备接受下一次的执行任务)

3, submit_async/2

该函数是完成异步执行submit 用户任务.

handle_cast({submit_async, Fun}, undefined) ->
    run(Fun),
    ok = worker_pool:idle(self()),
    {noreply, undefined, hibernate};

从上面可以看出该功能无需知道Fun 执行的返回结果, 只要Fun 执行完毕后, 就完成了此次任务.

worker_pool_worker 进程的state 转换太过复杂, 主要原因是用户进程的调用状态是由worker_pool_worker 进程来管理, worker_pool gen_server 只是管理 worker_pool_worker 进程的idle, ready 信息用来路由用户任务到idle 的 worker_pool_worker 进程.

这样做的弊端是增加了worker_pool_worker 进程的负担, 带来的好处是减轻了单点进程(worker_pool) 的压力, 由于worker_pool_worker 进程并不完全是一个, 因此, 这样的设计是利大于弊的.

worker_pool module

上面也提到了, worker_pool module 定义rpool 工作进程的调用进程. 用来管理工作进程的ready idle busy 状态,和Emysql pool 的管理相比, worker_pool 只使用了两种管理角色available(同Emysql pool 中的available), pending(等同于Emysql pool 中的waiting queue). 在Emysql pool 的管理中, 还有一个locked 角色, 就是正在被使用的资源, 而在worker_pool 中, 并没有与之参照的角色. 而是使用了 monitor 的方式, 在工作进程ready 的时候, worker_pool 进程会monitor 工作进程:

handle_cast({ready, WPid}, State) ->
    erlang:monitor(process, WPid),
    handle_cast({idle, WPid}, State);

在接收到工作进程'DOWN' 的消息, 会从available 角色中, 将工作进程delete :

handle_info({'DOWN', _MRef, process, WPid, _Reason},
            State = #state { available = Avail }) ->
    {noreply, State #state { available = ordsets:del_element(WPid, Avail) },
     hibernate};

之所以存在这样的不同, 是因为Emysql pool 中的元素是socket 链接, 需要存储用户进程和socket 链接之间的关联关系, 当使用socket 链接的用户进程exit 之后, 可以根据用户进程获取socket, 继而重置socket 链接. 而在rpool 中, pool 中的元素是Erlang process , 使用的是工作进程执行用户进程submit Fun 的方式, 当工作进程出现异常exit 时, work_pool 可以接收到工作进程'DOWN' 的消息, 并采取处理. 因而再使用locked 角色, 就会显得多余.

同样是因为pool 中元素性质的不同, monitor 用户进程的工作就从pool 的管理进程交给了 pool 中的元素.

总结

1, pool 中工作元素的数目和所使用的场景密切相关;

2, pool 中工作元素的性质, 决定了pool 管理需要使用到的角色(available/waiting/locked);

3, 从目前Emysql 和 rpool 的相关点来看, available 和waiting queue 对于一个pool 管理者而言, 是必不可少的;

4, 需要尽可能减轻管理者的压力, 或者增加管理者的进程数量.

下一篇的内容主要利用画图的方式梳理清楚worker_pool 中的进程之间的调用关系,以及进程内部state 的转换.