创建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核)：

把这个东西在提升一下，抽象出一个叫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}) -> ....

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)

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