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

Strategi Memulai Ulang Tingkat Lanjut

Pelajari strategi memulai ulang one_for_one, one_for_all, dan rest_for_one secara mendalam, serta pahami implikasinya terhadap toleransi kesalahan

Pelajaran 3 dari 411 langkah

Strategi Memulai Ulang Tingkat Lanjut adalah pelajaran Erlang OTP: Distributed & Fault-Tolerant Systems Programming gratis di CoddyKit. Ini adalah pelajaran 3 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Erlang OTP: Distributed & Fault-Tolerant Systems Programming, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Erlang OTP: Distributed & Fault-Tolerant Systems Programming mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

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?

Jawab di pelajaran interaktif

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.

Gratis untuk memulai

Belajar Erlang dengan tutor AI — gratis

Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.

Kursus: 12
Pelajaran: 48

Mulai belajar gratis Lihat kursus lengkapnya

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Strategi Memulai Ulang Tingkat Lanjut” gratis?

Ya — teks lengkap “Strategi Memulai Ulang Tingkat Lanjut” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Erlang OTP: Distributed & Fault-Tolerant Systems Programming, upgrade ke CoddyKit PRO. Kursus Erlang OTP: Distributed & Fault-Tolerant Systems Programming mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Strategi Memulai Ulang Tingkat Lanjut”?

Pelajari strategi memulai ulang one_for_one, one_for_all, dan rest_for_one secara mendalam, serta pahami implikasinya terhadap toleransi kesalahan Kamu berlatih Erlang OTP: Distributed & Fault-Tolerant Systems Programming dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Erlang OTP: Distributed & Fault-Tolerant Systems Programming?

Tidak diperlukan pengalaman sebelumnya. Erlang OTP: Distributed & Fault-Tolerant Systems Programming di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 3 dari 4.

Berapa lama pelajaran “Strategi Memulai Ulang Tingkat Lanjut” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Erlang OTP: Distributed & Fault-Tolerant Systems Programming ini?

Ya. Setiap pelajaran Erlang OTP: Distributed & Fault-Tolerant Systems Programming menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Pohon Supervisi Kompleks
Pengelolaan Proses Dinamis
Strategi Memulai Ulang Tingkat Lanjut
Jembatan Supervisor & Hierarki Proses Campuran

← Kembali ke Erlang OTP: Distributed & Fault-Tolerant Systems Programming