0Pricing
Erlang OTP: Distributed & Fault-Tolerant Systems Programming · Aula

Árvores de supervisão complexas

Projete e implemente hierarquias de supervisão aninhadas e complexas para gerenciar dependências e domínios de falha com eficácia.

Árvores de supervisão complexas é uma aula grátis de Erlang OTP: Distributed & Fault-Tolerant Systems Programming no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Erlang OTP: Distributed & Fault-Tolerant Systems Programming, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

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.

Perguntas Frequentes

A aula “Árvores de supervisão complexas” é grátis?

Sim — o texto completo de “Árvores de supervisão complexas” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming, atualize para CoddyKit PRO. O curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui 4 aulas no total.

O que vou aprender em “Árvores de supervisão complexas”?

Projete e implemente hierarquias de supervisão aninhadas e complexas para gerenciar dependências e domínios de falha com eficácia. Você pratica Erlang OTP: Distributed & Fault-Tolerant Systems Programming com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Erlang OTP: Distributed & Fault-Tolerant Systems Programming?

Nenhuma experiência prévia é necessária. Erlang OTP: Distributed & Fault-Tolerant Systems Programming no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.

Quanto tempo leva a aula “Árvores de supervisão complexas”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Erlang OTP: Distributed & Fault-Tolerant Systems Programming?

Sim. Cada aula de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Árvores de supervisão complexas
  2. Gerenciamento dinâmico de processos
  3. Estratégias avançadas de reinicialização
  4. Pontes de Supervisores e Hierarquias de Processos Mistas
← Voltar para Erlang OTP: Distributed & Fault-Tolerant Systems Programming