Erlang OTP: Distributed & Fault-Tolerant Systems Programming · Lezione

Alberi di supervisione complessi

Progetti e implementi gerarchie di supervisione annidate e articolate per gestire efficacemente dipendenze e domini di errore

Lezione 1 di 411 passaggi

Alberi di supervisione complessi è una lezione Erlang OTP: Distributed & Fault-Tolerant Systems Programming gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Erlang OTP: Distributed & Fault-Tolerant Systems Programming, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Erlang OTP: Distributed & Fault-Tolerant Systems Programming include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

Supervision Trees: The Basics

In Erlang, supervisors are special processes that oversee other processes, called children. If a child process crashes, the supervisor can restart it, ensuring fault tolerance.

A supervision tree is formed when a supervisor itself becomes a child of another supervisor. This creates a hierarchy, much like an organizational chart.

Why Complex Trees?

As applications grow, a single supervisor isn't enough. Complex supervision trees allow us to:

  • Manage dependencies: Group related processes so they start and stop together.
  • Isolate failures: A crash in one part of the tree won't necessarily bring down unrelated parts.
  • Improve modularity: Each supervisor can be responsible for a specific subsystem, making the application easier to understand and maintain.

Child Spec: Worker vs. Supervisor

Every process a supervisor manages is defined by a child specification. A child spec tells the supervisor how to start, restart, and shut down the child process.

Crucially, a child can be of two types:

  • worker: A regular process (like a gen_server) that performs application logic.
  • supervisor: Another supervisor process, forming a nested level in the tree.

The Worker: my_worker_module

Let's start with a simple worker process. This gen_server will be the leaf node in our supervision tree. It just prints messages when it starts or receives calls.

-module(my_worker_module).
-behaviour(gen_server).

-export([start_link/1, init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).

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

init(Id) ->
    io:format("Worker ~p starting...~n", [Id]),
    {ok, Id}.

handle_call(Req, _From, State) ->
    io:format("Worker ~p received call: ~p~n", [State, Req]),
    {reply, ok, State}.

handle_cast(Msg, State) ->
    io:format("Worker ~p received cast: ~p~n", [State, Msg]),
    {noreply, State}.

handle_info(Msg, State) ->
    io:format("Worker ~p received info: ~p~n", [State, Msg]),
    {noreply, State}.

terminate(_Reason, State) ->
    io:format("Worker ~p terminating...~n", [State]).

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

The Nested Supervisor: my_nested_sup

This supervisor will manage our my_worker_module processes. It defines two workers, 'WorkerA' and 'WorkerB', each with slightly different restart strategies.

Notice how its child_specs define type => worker.

-module(my_nested_sup).
-behaviour(supervisor).

-export([start_link/0, init/1]).

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

init([]) ->
    SupFlags = #{
        strategy => one_for_one,
        intensity => 10,
        period => 1
    },
    ChildSpecs = [
        #{
            id => worker_A,
            start => {my_worker_module, start_link, ["WorkerA"]},
            type => worker,
            restart => permanent,
            shutdown => 5000,
            modules => [my_worker_module]
        },
        #{
            id => worker_B,
            start => {my_worker_module, start_link, ["WorkerB"]},
            type => worker,
            restart => transient,
            shutdown => 2000,
            modules => [my_worker_module]
        }
    ],
    {ok, {SupFlags, ChildSpecs}}.

The Top-Level Supervisor: my_app_sup

This is the root of our complex tree. It supervises my_nested_sup. Notice that its child_spec for my_nested_sup has type => supervisor. This is how you build nested trees!

-module(my_app_sup).
-behaviour(supervisor).

-export([start_link/0, init/1]).

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

init([]) ->
    SupFlags = #{
        strategy => one_for_one,
        intensity => 10,
        period => 1
    },
    ChildSpecs = [
        #{
            id => my_nested_sup_child,
            start => {my_nested_sup, start_link, []},
            type => supervisor,
            restart => permanent,
            shutdown => infinity,
            modules => [my_nested_sup]
        }
    ],
    {ok, {SupFlags, ChildSpecs}}.

Running the Complex Tree

To see our tree in action, compile all three modules (my_worker_module.erl, my_nested_sup.erl, my_app_sup.erl) and then start the top-level supervisor. You'll see the workers start up!

You can use supervisor:which_children(PidOrName) to inspect the tree.

% In the Erlang shell:

c(my_worker_module).
c(my_nested_sup).
c(my_app_sup).

{ok, MySupPid} = my_app_sup:start_link().

% Check the children of the top-level supervisor:
supervisor:which_children(MySupPid).

% Find the nested supervisor's PID:
{_, NestedSupPid, _, _} = lists:keyfind(my_nested_sup_child, 1, supervisor:which_children(MySupPid)).

% Check the children of the nested supervisor:
supervisor:which_children(NestedSupPid).

Visualizing the Hierarchy

Our complex supervision tree looks like this:

  • my_app_sup (top-level supervisor)
    • supervises my_nested_sup (a child supervisor)
      • supervises worker_A (a worker process)
      • supervises worker_B (a worker process)

This structure ensures that if worker_A crashes, only my_nested_sup handles it. If my_nested_sup itself crashes, my_app_sup will restart it, bringing worker_A and worker_B back to life.

Benefits of Complex Trees

Complex supervision trees are a cornerstone of building robust Erlang applications. They provide:

  • Fault Isolation: Failures are contained to specific branches.
  • Logical Grouping: Components with related functions are supervised together.
  • Clear Responsibilities: Each supervisor has a well-defined set of processes it's responsible for.
  • Scalability: Easier to add or remove subsystems without disrupting the entire application.

Quick Check: Supervision Trees

Which of the following are key benefits of using complex (nested) supervision trees in Erlang?

Recap: Complex Supervision

Today, we explored complex supervision trees in Erlang. We learned that supervisors can manage other supervisors, creating nested hierarchies. This powerful pattern enables robust fault tolerance by isolating failures, managing dependencies, and improving the modularity of your applications. By defining child specs with type => supervisor, you can build intricate and resilient Erlang systems.

Gratis per iniziare

Impara Erlang con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi
12
Lezioni
48

Domande Frequenti

La lezione «Alberi di supervisione complessi» è gratuita?

Sì — il testo completo di «Alberi di supervisione complessi» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Erlang OTP: Distributed & Fault-Tolerant Systems Programming, passa a CoddyKit PRO. Il corso Erlang OTP: Distributed & Fault-Tolerant Systems Programming include 4 lezioni in totale.

Cosa imparerò in «Alberi di supervisione complessi»?

Progetti e implementi gerarchie di supervisione annidate e articolate per gestire efficacemente dipendenze e domini di errore Eserciti Erlang OTP: Distributed & Fault-Tolerant Systems Programming con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Erlang OTP: Distributed & Fault-Tolerant Systems Programming?

Non è richiesta alcuna esperienza precedente. Erlang OTP: Distributed & Fault-Tolerant Systems Programming su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Alberi di supervisione complessi»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Erlang OTP: Distributed & Fault-Tolerant Systems Programming?

Sì. Ogni lezione Erlang OTP: Distributed & Fault-Tolerant Systems Programming include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Alberi di supervisione complessi
  2. Gestione dinamica dei processi
  3. Strategie avanzate di riavvio
  4. Bridge dei supervisor e gerarchie di processi miste
← Torna a Erlang OTP: Distributed & Fault-Tolerant Systems Programming