Supervisor Behavior Analysis and practice

1. Introductionto write a system of high fault tolerance and stability, Erlang Supervisor is the core idea to solve this problem. Through the establishment of a monitoring tree, to organize the relationship between processes, by determining the restart strategy, sub-process specification and other parameter information to determine the behavior of the process and the process, and in the event of failure to deal with the method. A brief introduction to the Supervisor API:
  Start_link (Module, Args), Startlink_ret () Start_link (Supname, Module, Args), Startlink_ret ()    Used to start a monitoring tree, it calls Module:init (Args) to get configuration information for the monitoring tree, Supname represents the name of the monitoring tree, and the default is PID ().
start_child (Supref, Childspec), Startchild_ret () used to supref dynamically add child processes to the monitoring tree, childspec the specification of the child process.   terminate_child (Supref, Id), Result used to terminate a running child process. Note: If this is the Simple_one_for_one type ID = PID (), if the other type ID is the ID of the specification.   delete_child (Supref, Id), Result used to delete a child process that has stopped, but does not include a temporary (temporary) child process, and the temporary child process is deleted as soon as it stops. The Simple_one_for_one is invalid for the governor, because when the child process is terminated, the information related to the child process is deleted, not the modified state, the details supervisor the source code.   restart_child (Supref, Id), Result used to restart a stopped and restartable child process. Temporary (temporary) child processes are meaningless. The Simple_one_for_one is invalid for the governor.  Which_children (supref), [{Id, Child, Type, Modules}] Lists all child processes for the number of monitors. Note: When the monitoring tree has a large number of child processes, calling this method can easily cause memory overflow.   Count_children (supref), proplistofcounts Counts the number of child processes. Return list: [{specs, int ()}, {active, int ()}, {supervisors, int ()}, {workers, int ()}]
        check_childspecs (childspecs), Result
   Verifies whether a child process of a specification exists.2. AnalysisHow to construct a monitoring tree, the process and the process of the respective characteristics of what, there is any connection,The init () neutron process parameter description, as well as the restart strategy used by the monitoring tree, shows all of this in the restart frequency.2.1 Restart Policy     One_for_one: A child process stops only restarting the child process One_for_all: One child process stops rebooting all child processes
Rest_for_one: For a child process list, a child process stops, stops the child process in the list, and then restarts the child processes in sequence Simple_one_for_one: Its restart policy is the same as one_for_one, but it must be a sub-process of the same type and must be dynamically joined.2.2 Maximum Restart frequencyMaximum Restart frequency ( maximum restart frequency)Refers to the maximum number of restarts: MaxR, maximum restart time: Maxt, that is, in maxt time, the maximum can be restarted MaxR times, if more than this frequency, the entire monitoring tree will be terminated.2.3 Child Process DescriptionTemplate for sub-process specification:

1Child_spec () ={id,startfunc,restart,shutdown,type,modules}2Id =Term ()3Startfunc ={M,f,a}4M = F =Atom ()5A =[Term ()]6Restart = Permanent | transient |Temporary7Shutdown = Brutal_kill |int() >0 |Infinity8Type = Worker |Supervisor9Modules = [Module] |DynamicTenModule = Atom ()

Id: The unique identifier of the child process, which is the ID parameter in TERMINATE_CHILD/2,RESTART_CHILD/2,DELETE_CHILD/2 when supervisor is a non-simple_one_for_one type. Startfunc: The start function of the child process. Restart: Restart type permanent: Child process is always restarted transient: the child process can be restarted in the case of a normal exit temporary: the child process is not restarted under any circumstances, and the child process of the restart type is immediately removed from the restart after it is terminated. Therefore, RESTART_CHILD/2,DELETE_CHILD/2 is not valid for this type of child process

　　　　Shutdown: Off time

Brutal_kill: The child process will be terminated immediately and unconditionally, via Exit (PID (), kill). 　 Int () >0: Within the timeframe, the child process will be gracefully closed through exit (PID (), shutdown), waiting for information to be returned, or the child process will be terminated immediately by exit (PID (), kill) If the message is not returned after the time range is exceeded. Infinity: When a child process is another monitoring tree, it gives enough time for the child monitoring tree to close, or you can set the parameter to the worker process, but be aware that the finalization of the monitoring tree depends on the child process and that his cleanup results must always be returned. (not verified)

Type: Subtype of child process worker | Supervisor

Modules : Callback Module

If the child process is supervisor, Gen_server, GEN_FSM, then modules is the list of callback module name, and dynamic if it is gen_event. (not verified)

3. Example3.1 Simple_one_for_one Instances

1-Module(add_sup).2  3-behaviour (supervisor).4  5-Export([start_link/0, start_child/0]).6-Export([INIT/1]).7  8-define (SERVER,?MODULE).9  TenStart_link () OneSupervisor:start_link ({local,? SERVER},?MODULE, []). AStart_child () -Supervisor:start_child (?MODULE, []). -   theInit ([]) -Restartstrategy =Simple_one_for_one, -Maxrestarts = 2, -Maxsecondsbetweenrestarts = 100, +   -Supflags ={restartstrategy, maxrestarts, maxsecondsbetweenrestarts}, +   ARestart =Permanent, atShutdown = 20000, -Type =worker, -   -Achild ={add2, {add2, Start_link, []}, - Restart, Shutdown, Type, [ADD2]}, -   in{OK, {supflags, [Achild]}}.

The child process is dynamically joined by calling Start_child/0.

The startup function of the ADD2 module (note: Because Simple_one_for_one requires the same type of child process to be joined, so the startup function has no name):

1 start_link ()2      gen_server:start_link (? MODULE, [], []).

Add_sup is the Simple_one_for_one monitoring tree, its dynamic addition to the child process has no name: through TERMINATE_CHILD/2 can terminate the Add_sup child process, after the termination of the child process will be deleted, cannot restart, so Delete_ CHILD/2, RESTART_CHILD/2 toThe child process of the Simple_one_for_one type's monitoring tree is not valid. 3.2 Normal child processes added to the monitoring tree

Normal sub-process code:

1-Module(Common).2-author ("Administrator").3  4-Export([start_link/0, START_LOOP/2]).5  6Start_link ()7Res = Proc_lib:start_link (? MODULE, Start_loop, [self (),? MODULE]),%%start a normal process8 Res.9  TenStart_loop (Parent,name) OneRegister (Name, self ()),%%name the normal process, otherwise the default is PID ().  A Proc_lib:init_ack (Parent, {OK, self ()}), - Loop (). -   theLoop () - Receive -Args- -Io:format ("Args:~p~n", [Args]) + End.

In the process of creating a normal process above, you can use Proc_lib:start_link, which is the synchronization of the creation of the child process. Note: You cannot create a process under the monitoring tree with spawn, which causes the process to be created to not be restarted by the monitoring tree after it is terminated. The following are the specifications of the subprocess:

1 {Common, {Common, Start_link, []}, permanent, 10000, worker, [common]}

Create a monitoring tree:

Termination and restart of the normal child process:

3.3 Restarting a dynamically added child process

for the monitoring tree a sub-process is another monitoring tree B, the monitoring tree B has a number of dynamically joined sub-processes, if the B restarts after the dynamic join of the child process will no longer exist, if the B restart after the need to re-join these sub-processes, one, record the dynamic join the child process information, When the monitoring tree restarts and then dynamically joins the previous sub-processes, second, improve the implementation of the supervisor, you can restart the dynamic join of the sub-process (not practice,RABBITMQ in the Supervisor modified to achieve this function).

The following example is a simple implementation method for the Simple_one_for_one monitoring tree:1.Create an ETS label on a single sub-process

1 init ([])--2 {OK, ets:new (proc_ets,[duplicate_bag, public, named_table, {keypos,1}])}.

Current Monitoring tree

2. Dynamically join sub-processes and log information, restart the child monitoring tree, and dynamically join the child process

1-Module(add_sup).2-include ("Ets_arg.hrl").3-behaviour (supervisor).4  5-Export([start_link/0, START_CHILD/1]).6-Export([INIT/1]).7  8-define (SERVER,?MODULE).9  Ten-spec (Start_link () One{OK, PID:: PID ()} | Ignore |{error, Reason:: Term ()}). AStart_link () -{OK, Pid} = Supervisor:start_link ({local,? SERVER},?MODULE, []), -  CaseEts:lookup (? Ets? MODULE) of theObject--Load_dynamic_proc (object)%%dynamically adding stored sub-processes - End, - {OK, Pid}. -   +Start_child (_type) -{OK, Pid} = Supervisor:start_child (?MODULE, []), +  Case_type of ARestartOK; at_->ets:insert (? Ets,{? MODULE,? Simple, []})%%stores information that dynamically joins child processes - End, - {OK, Pid}. -   -Init ([]) -Restartstrategy =Simple_one_for_one, inMaxrestarts = 2, -Maxsecondsbetweenrestarts = 100, to   +Supflags ={restartstrategy, maxrestarts, maxsecondsbetweenrestarts}, -   theRestart =Permanent, *Shutdown =Brutal_kill, $Type =worker,Panax Notoginseng   -Achild ={add2, {add2, Start_link, []}, the Restart, Shutdown, Type, [ADD2]}, +   A {OK, {supflags, [Achild]}}. the   +Load_dynamic_proc ([]) - OK; $Load_dynamic_proc ([h| T]) $ Start_child (restart), - Load_dynamic_proc (T), -{OK, H}.

The current monitoring tree dynamically joins the child process information Table monitoring tree Add_sup Restart, re-join the same type of child process dynamically4. SummarySupervisor is one of Erlang's four behavioral patterns, but essentially the Gen_server implementation provides business support. Supervisor provides support for writing fault-tolerant, high-stability, built-in monitoring tree system is powerful, easy to understand, diverse structure. But the when top layer monitoring process crashes and the entire system crashes. Child processes that are dynamically joined to the monitoring process cannot be restarted. These features are used to build applications when building any application (application).   Blog Address: http://www.cnblogs.com/liuweiccy/p/4622075.htmlSource Address: Https://github.com/liuweiccy/test_supGood code is a work of art, it needs to be carefully carved!

Supervisor Behavior Analysis and practice