Fortgeschrittene Neustartstrategien
Vertiefen Sie sich in die Neustartstrategien one_for_one, one_for_all und rest_for_one und verstehen Sie ihre Auswirkungen auf die Fehlertoleranz
Fortgeschrittene Neustartstrategien ist eine kostenlose Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Intro to Restart Strategies
Welcome to a crucial topic in Erlang: restart strategies! These define how a supervisor reacts when one of its child processes crashes.
Understanding these strategies is key to building fault-tolerant and self-healing systems, which is a hallmark of Erlang/OTP.
Supervisors: The Fault Managers
Before diving in, let's quickly recap: a supervisor is a special process that monitors other processes (its children).
- If a child process dies, the supervisor detects it.
- Based on its configured restart strategy, the supervisor decides how to bring the system back to a healthy state.
- This ensures your application can recover from individual process failures automatically.
`one_for_one`: Isolated Restarts
The one_for_one strategy is the simplest and most common. When a child process terminates:
- Only the failing child process is restarted.
- All other sibling processes remain unaffected and continue running.
This strategy is ideal for systems where child processes are largely independent of each other, such as individual client connections.
`one_for_one` in Action
Let's see one_for_one. We'll have a supervisor managing a single worker. When the worker crashes, only it restarts.
To run:
1. Compile: c(worker_gen). c(supervisor_one_for_one).
2. Start supervisor: supervisor_one_for_one:start_link().
3. Crash worker: worker_gen:crash(worker_1).
Observe the output in your Erlang shell.
-module(worker_gen).
-behaviour(gen_server).
-export([start_link/1, init/1, handle_call/3, terminate/2, crash/1]).
start_link(Id) ->
gen_server:start_link({local, Id}, ?MODULE, Id, []).
init(Id) ->
io:format("Worker ~p (~p) started.~n", [Id, self()]),
{ok, Id}.
handle_call(crash, _From, State) ->
exit(i_crashed),
{reply, ok, State};
handle_call(_Req, _From, State) ->
{reply, ok, State}.
terminate(_Reason, Id) ->
io:format("Worker ~p (~p) terminated.~n", [Id, self()]).
crash(Id) ->
gen_server:call(Id, crash).
-module(supervisor_one_for_one).
-behaviour(supervisor).
-export([start_link/0, init/1]).
start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
init([]) ->
ChildSpec = #{
id => worker_1,
start => {worker_gen, start_link, [worker_1]},
restart => permanent,
shutdown => 5000,
type => worker,
modules => [worker_gen]
},
{ok, #{
strategy => {one_for_one, 3, 5},
children => [ChildSpec]
}}.
`one_for_all`: All for One Failure
The one_for_all strategy takes a more drastic approach:
- If any child process terminates, all other child processes are first terminated.
- Then, all child processes (including the one that crashed) are restarted.
This is useful when your child processes are tightly coupled and require a consistent, synchronized state. A failure in one implies a need to reset the entire group.
`one_for_all` in Action
Here, a supervisor manages two workers. Crash one, and both will restart.
To run:
1. Compile: c(worker_gen). c(supervisor_one_for_all).
2. Start supervisor: supervisor_one_for_all:start_link().
3. Crash worker: worker_gen:crash(worker_A).
Notice how both worker_A and worker_B restart.
-module(worker_gen).
-behaviour(gen_server).
-export([start_link/1, init/1, handle_call/3, terminate/2, crash/1]).
start_link(Id) ->
gen_server:start_link({local, Id}, ?MODULE, Id, []).
init(Id) ->
io:format("Worker ~p (~p) started.~n", [Id, self()]),
{ok, Id}.
handle_call(crash, _From, State) ->
exit(i_crashed),
{reply, ok, State};
handle_call(_Req, _From, State) ->
{reply, ok, State}.
terminate(_Reason, Id) ->
io:format("Worker ~p (~p) terminated.~n", [Id, self()]).
crash(Id) ->
gen_server:call(Id, crash).
-module(supervisor_one_for_all).
-behaviour(supervisor).
-export([start_link/0, init/1]).
start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
init([]) ->
Child1 = #{
id => worker_A,
start => {worker_gen, start_link, [worker_A]},
restart => permanent, shutdown => 5000, type => worker, modules => [worker_gen]
},
Child2 = #{
id => worker_B,
start => {worker_gen, start_link, [worker_B]},
restart => permanent, shutdown => 5000, type => worker, modules => [worker_gen]
},
{ok, #{
strategy => {one_for_all, 3, 5},
children => [Child1, Child2]
}}.
`rest_for_one`: Cascade Restarts
The rest_for_one strategy offers a middle ground:
- If a child process terminates, it and all subsequent children (those defined after it in the supervisor's child list) are terminated.
- Then, the failed child and all subsequent children are restarted.
- Children defined before the failed child are left untouched.
This is useful when processes have sequential dependencies, where a failure in an earlier stage might invalidate the state of later stages.
`rest_for_one` in Action
We have three workers: X, Y, Z. If Y crashes, Y and Z restart, but X remains active.
To run:
1. Compile: c(worker_gen). c(supervisor_rest_for_one).
2. Start supervisor: supervisor_rest_for_one:start_link().
3. Crash worker: worker_gen:crash(worker_Y).
See worker_X stay running, while worker_Y and worker_Z restart.
-module(worker_gen).
-behaviour(gen_server).
-export([start_link/1, init/1, handle_call/3, terminate/2, crash/1]).
start_link(Id) ->
gen_server:start_link({local, Id}, ?MODULE, Id, []).
init(Id) ->
io:format("Worker ~p (~p) started.~n", [Id, self()]),
{ok, Id}.
handle_call(crash, _From, State) ->
exit(i_crashed),
{reply, ok, State};
handle_call(_Req, _From, State) ->
{reply, ok, State}.
terminate(_Reason, Id) ->
io:format("Worker ~p (~p) terminated.~n", [Id, self()]).
crash(Id) ->
gen_server:call(Id, crash).
-module(supervisor_rest_for_one).
-behaviour(supervisor).
-export([start_link/0, init/1]).
start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
init([]) ->
ChildA = #{
id => worker_X,
start => {worker_gen, start_link, [worker_X]},
restart => permanent, shutdown => 5000, type => worker, modules => [worker_gen]
},
ChildB = #{
id => worker_Y,
start => {worker_gen, start_link, [worker_Y]},
restart => permanent, shutdown => 5000, type => worker, modules => [worker_gen]
},
ChildC = #{
id => worker_Z,
start => {worker_gen, start_link, [worker_Z]},
restart => permanent, shutdown => 5000, type => worker, modules => [worker_gen]
},
{ok, #{
strategy => {rest_for_one, 3, 5},
children => [ChildA, ChildB, ChildC]
}}.
Selecting the Best Strategy
Choosing the right strategy depends on your application's architecture and process dependencies:
one_for_one: Use for independent processes, like individual client connections or request handlers.one_for_all: Best for tightly coupled processes that must always be in a consistent state together (e.g., a group of processes managing a single resource).rest_for_one: Suitable for sequential pipelines or layered systems where a failure in an earlier stage affects subsequent stages.
Test Your Knowledge
You are building a system where a primary worker fetches data, and two secondary workers process different aspects of that data. If the primary worker fails, the secondary workers cannot continue with stale data and must also restart. If a secondary worker fails, the others are unaffected. Which strategy is most appropriate for the primary worker and its dependent secondary workers?
Recap: Mastering Restarts
You've explored Erlang's powerful restart strategies:
one_for_one: Restarts only the failed child, keeping others running.one_for_all: Restarts all children if any one fails, ensuring full consistency.rest_for_one: Restarts the failed child and all subsequent children in the list.
These strategies are fundamental to building robust, self-healing applications in Erlang, allowing your system to recover from failures gracefully.
Lerne Erlang mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 12
- Lektionen
- 48
Häufig gestellte Fragen
Ist die Lektion „Fortgeschrittene Neustartstrategien“ kostenlos?
Ja — der vollständige Text von „Fortgeschrittene Neustartstrategien“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Fortgeschrittene Neustartstrategien“?
Vertiefen Sie sich in die Neustartstrategien one_for_one, one_for_all und rest_for_one und verstehen Sie ihre Auswirkungen auf die Fehlertoleranz Du übst Erlang OTP: Distributed & Fault-Tolerant Systems Programming mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Erlang OTP: Distributed & Fault-Tolerant Systems Programming zu starten?
Keine Vorkenntnisse erforderlich. Erlang OTP: Distributed & Fault-Tolerant Systems Programming auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Fortgeschrittene Neustartstrategien“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Lektion Code schreiben und ausführen?
Ja. Jede Erlang OTP: Distributed & Fault-Tolerant Systems Programming-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Komplexe Supervisor-Bäume
- Dynamische Prozessverwaltung
- Fortgeschrittene Neustartstrategien
- Supervisor-Bridges und gemischte Prozesshierarchien