創建gen_server組解決單process瓶頸

併發和順序是一個令人糾結的問題。

下面是開發中遇到的一個問題
常規時間，系統表現的很“端莊”，不折騰CPU，不玩弄Mem。可是到高峯時，這個傢伙就開始變態了。內存狂飆，直至swap最後無法響應。這個狀況，當時折騰了一天多。始終無法找到問題所在。最後通過排查及yufeng的幫助，將問題鎖定在某些局部process。

Erlang中默認，所有的Process具有同等的執行機會。
我們的系統中有上萬個process處理客戶連接，上萬個cient process的數據，通過一個data_trans prcess處理。而這個process通過Message將數據發送到其他節點。問題就是這裏。

client processes將數據發送給data_trans process後，數據的處理就是一個順序的過程了，從消息隊列中獲取一條數據，打包，然後發送到其他Node。顯然，在client process增加時，data_trans process的數據處理能力，已經跟不上了。所以導致系統惡化，最終崩潰。

怎麼解決呢？
1，可以限定系統的併發連接數，保證服務質量（因爲系統某些不足，導致此方法不可行）
2，加大data_trans處理能力，減少瓶頸

至於方法2，也有很多具體的實施方法：將數據打包和數據傳輸部分進行功能分割；創建多個data_trans組成一個process group
其中創建多個process，對代碼改動最少，所以爲最終選擇。

根據yufeng的建議，實現如下:
使用一個supervisour(simple_one_for_one)管理所有的data_trans進程
data_trans的數目，與scheduler數目一致（8核則數目爲8)
每個data_trans name爲name_N (N爲 1..SchedulerNumber)
調用data_trans時，根據caller，獲取當前執行scheduler的X，直接將request跳轉到name_X的進程去處理.

好處：
根據scheduler數目創建進程組，減少單個進程處理瓶頸
根據scheduler id直接跳轉到進程組中某個進程，減少了中間查詢，實現直接映射，效率更高.


簡單的示意圖（假設系統4核)：

引用

caller 1 (scheduler_id 3) -\   /------|- process_1 |\
                                          \/                                 \
caller 2 (scheduler_id 1) --/ \     /--|- process_2 |--
                                             \  /                                 process supervisor(simple_one_for_one)
caller 3 (scheduler_id 4) -\    / \----|- process_3 |--  
                                          \/                                /
caller 4 (scheduler_id 2) _/ \____|- process_4 |/

                                  （直接映射)

把這個東西在提升一下，抽象出一個叫gen_server_cter的behaviour，其組裝多個子gen_server process，調用時，根據調用者的當前scheduler id映射到對應子process name。

gen_server_cter接口：
start_link(CterName, CbMod, Args)
啓動gen_server組
參數:CterName － cter name
    CbMod － gen_server callback module
    Args - 傳遞給CbMod的參數

cast(CbMod, Req)
異步調用請求

call(CbMod, Req) ->
同步調用請求

其中CbMod module必須實現一個get_name/1函數，用來實現scheduler id到進程名的映射.
比如(假設CbMod爲my_module)
get_name(SchedulerId) ->
    list_to_atom(lists:concat([my_module, SchedulerId])).

用法：
gen_server_cter:start_link(my_module_group, my_module, Args)
gen_server_cter:cast(my_module, Req)
gen_server_cter:call(my_module, Req)

 

 

就是下面這個module完整代碼

-module(gen_server_cter).
-behaviour(supervisor).

-export([start_link/3]).
-export([cast/2, call/2]).

%% for supervisor
-export([init/1]).

-export([behaviour_info/1]).

-spec behaviour_info(atom()) -> 'undefined' | [{atom(), byte()}].
behaviour_info(callbacks) ->                        
    [{get_name,1}];
behaviour_info(_Other) ->
    undefined.

%% @doc start the server
start_link(CterName, CbMod, Args) ->
    Ret = {ok, _Pid} = supervisor:start_link({local, CterName}, ?MODULE, [{callback, CbMod}, {args, Args}]),
    %io:format("pid:~p~n", [_Pid]),
    N = erlang:system_info(schedulers),
    [{ok, _} =  supervisor:start_child(CterName, [{index, I}]) || I <- lists:seq(1, N)],
    Ret. 

cast(CbMod, Req) ->
    Handler = select_handler(CbMod),
    %io:format("handler is:~p~n", [Handler]),
    gen_server:cast(Handler, Req).

call(CbMod, Req) ->
    Handler = select_handler(CbMod),
    gen_server:call(Handler, Req).


%%
%% supervisor callbacks
%%
init([{callback, CbMod}, {args, Args} | _]) -> 
    Strategy = {simple_one_for_one, 10, 10},
    Mod = {undefined, {CbMod, start_link, Args},
		  permanent, 3000, worker, [CbMod]},
    {ok, {Strategy, [Mod]}}.

%% internal API
select_handler(CbMod) ->
    I = erlang:system_info(scheduler_id),
    CbMod:get_name(I).

 

update(2009.11.24):

在callback模塊中，需要做一些小改動,需要添加一個export函數：

get_name(N :: integer()) -> atom().

返回此server對應的name

 

還需要修改start_link爲：

start_link({index, I}) -> ....