【问题标题】:Erlang: How to properly dispatch a gen_server with start_child in a supervisor and call the APIErlang:如何在主管中正确调度带有 start_child 的 gen_server 并调用 API
【发布时间】:2017-01-10 20:31:21
【问题描述】:

我的 cavv 应用程序中有一个 gen_server,我需要先启动它才能执行调用。我想为此使用命令调度程序。举个简短​​的例子,这是 gen_server 的 API:

gen_server: cavv_user

-module(cavv_user).

-behavior(gen_server).

-define(SERVER(UserId), {via, gproc, {n, l, {?MODULE, UserId}}}).

start_link(UserId) ->
    gen_server:start_link(?SERVER(UserId), ?MODULE, [UserId], []).

change_email_address(UserId, EmailAddress) ->
    gen_server:call(?SERVER(AggregateId), {execute_command, #change_user_email_address{user_id=UserId, email_address=EmailAddress}}). 

在调用cavv_user:change_email_address(). 之前,我需要启动cavv_user。我这样做是作为主管中的simple_one_for_one 孩子,就像这样:

主管:cavv_user_sup

-module(cavv_user_sup).

-behaviour(supervisor).

-define(CHILD(ChildName, Type, Args), {ChildName, {ChildName, start_link, Args}, temporary, 5000, Type, [ChildName]}).

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

start_child(UserId) ->
    supervisor:start_child(?SERVER, [UserId]).

init([]) ->
    RestartStrategy = {simple_one_for_one, 1, 5},

    Children = [?CHILD(cavv_user, worker, [])],

    {ok, { RestartStrategy, Children} }.

我现在面临的问题是如何将命令分派cavv_user。我想确保首先使用start_child 启动正确的用户,然后调用cavv_user:change_email_address().

我找到了这个 anwser,可以使用 dispatcherErlang: what supervision tree should I end with writing a task scheduler?

所以我创建了一个命令调度程序,最终得到了一个cavv_user_dispatcher 和一个cavv_user_dispatcher_sup,它们又包含cavv_user_dispatcher 和更早的cavv_user_sup

         cavv_user_dispatch_sup
            |               |
 cavv_user_dispatcher       |
       (gen_server)         |
                            |
                            |
                      cavv_user_sup
                        |   |   |
                 cavv_user_1...cavv_user_N

cavv_user_dispatcher

这很好用。

我现在面临的问题是,如何正确编写cavv_user_dispatcher中的代码?我面临代码重复的问题。如何正确调用start_child并调用cavv_user的相应API?

我应该像这样使用某种Fun吗?

-module(cavv_user_dispatcher).

dispatch_command(UserId, Fun) ->
    gen_server:call(?SERVER, {dispatch_command, {UserId, Fun}}).

handle_call({dispatch_command, {UserId, Fun}}, _From, State) ->
    cavv_user_sup:start_child(UserId),
    Fun(), %% How to pass: cavv_user:change_email_address(..,..)?
    {reply, ok, State};

或者像这样复制cavv_user的API?

-module(cavv_user_dispatcher).

change_user_email_address(UserId, EmailAddress) ->
    gen_server:call(?SERVER, {change_user_email_address, {UserId, EmailAddress}}).

handle_call({change_user_email_address, {UserId, EmailAddress}}, _From, State) ->
    cavv_user_sup:start_child(UserId),
    cavv_user:change_email_address(UserId, EmailAddress),
    {reply, ok, State};

或者我应该将cavv_user 中的命令记录 重新使用到某种实用程序中以正确构建它们并传递它们?也许有更好的方法来传递我想在cavv_user调用的函数?

我想尽可能以最好的 Erlang 方式解决问题,而不是重复代码。

【问题讨论】:

    标签: erlang dispatcher erlang-otp erlang-supervisor gen-server


    【解决方案1】:

    您的调度员是否应该处理其他命令?

    • 如果是,那么下一个命令将如何到来,我的意思是请求者是否知道用户的进程pid?

      • 如果是,那么您需要 2 个函数,一个用于创建用户,它将 pid 返回给请求者以进行下一次调用,另一个通过将命令发送到给定 pid 来处理下一个请求

      • 如果不是,那么您还需要 2 个函数,一个用于创建用户并将 user_id 与用户进程 pid 一起存储,另一个用于通过检索进程 pid 来处理下一个请求,然后将其转发给命令 (我想这就是你想要做的)。

    • 如果不是,那么您不需要处理任何命令,并且应该在创建用户进程时直接传递电子邮件地址。请注意,这适用于所有情况,因为您需要不同的界面来创建用户。

    我会以这种方式修改您的代码(未经测试,为时已晚 :o)!)

    -module(cavv_user_dispatcher).
    
    create_user(UserId,UserMail) ->
        gen_server:call(?SERVER,{new_user,UserId,UserMail}).
    
    % Args is a list of argument, empty if
    % F needs only one argument (the user Pid)
    dispatch_command(UserId, Fun, Args) ->  
        gen_server:call(?SERVER, {dispatch_command, {UserId, Fun,Args}}).
    
    handle_call({dispatch_command, {UserId, Fun,Args}}, _From, State) ->
        Pid = get_pid(UserId,State),
        Answer = case Pid of
            unknown_user_id -> unknown_user_id;
            _ -> apply(Fun,[Pid|Args]),
                 ok
        end,
        {reply, Answer, State};
    handle_call({new_user,UserId,UserMail},_From,State) ->
        % verify that the user id does not already exists
        CheckId = check_id(UserId,State),
        {Answer,NewState} = case CheckId of 
            false -> {already_exist,State};
            true  -> {ok,Pid} = cavv_user_sup:start_child(UserId,UserMail)
                     {ok,[{UserId,Pid}|State]}
                     % State must be initialized as an empty list in the init function.
        {reply, Answer, NewState};
    ...
    get_pid(UserId,State) ->
        proplists:get_value(UserId, State, unknown_user_id).
    check_id(UserId,State) -> 
        not proplists:is_defined(UserId, State).
    

    并且用户主管必须这样修改:

    start_child(UserId,UserMail) -> % change arity in the export
    supervisor:start_child(?SERVER, [UserId,UserMail]).
    

    然后是用户服务器:

    start_link(UserId,UserMail) ->
    gen_server:start_link(?SERVER(UserId), ?MODULE, [UserId,UserMail],[]).
    
    init([UserId,UserMail]) ->
        {ok,[{user_id,UserId},{user_mail,UserMail}]}.
    

    【讨论】:

    • 我明白了。调度程序应该调用 start_child,并返回一个 Pid。然后我应该使用 Pid 并将其传递给 cavv_user:change_email_address(UserRef, EmailAddress) 作为对该进程的引用,因为理论上该进程将来也可以在另一台机器上启动。我现在正在传递 User_Id,这在我的设计中是一件坏事。
    • 你可以照你说的做,不方便的是调用者需要知道进程ID,这是一个奇怪的信息来交换(没意义,可能会改变......),我建议你的代码将 {UserId,Pid} 对存储在 proplist 中,这是一个非常简单的实现,我认为 ets 应该更好,而且它没有显示如何管理用户进程的死亡,所以在那种状态下,proplist 永远不会已清理,用户无法重新连接,但这是尝试回答您的问题的起点。
    猜你喜欢
    • 1970-01-01
    • 2023-03-17
    • 2011-06-18
    • 2015-12-15
    • 2013-01-22
    • 2015-04-18
    • 2016-01-13
    • 2015-07-12
    • 1970-01-01
    相关资源
    最近更新 更多