Erlang OTP: Distributed & Fault-Tolerant Systems Programming · บทเรียน

กลยุทธ์การเริ่มต้นใหม่ขั้นสูง

เจาะลึกกลยุทธ์การเริ่มต้นใหม่แบบ one_for_one, one_for_all และ rest_for_one พร้อมทำความเข้าใจผลกระทบต่อความทนทานต่อความขัดข้อง

บทเรียน 3 จาก 411 ขั้นตอน

กลยุทธ์การเริ่มต้นใหม่ขั้นสูง เป็นบทเรียน Erlang OTP: Distributed & Fault-Tolerant Systems Programming ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Erlang OTP: Distributed & Fault-Tolerant Systems Programming และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Erlang OTP: Distributed & Fault-Tolerant Systems Programming มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

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.

เริ่มต้นได้ฟรี

เรียนรู้ Erlang ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 12
บทเรียน: 48

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “กลยุทธ์การเริ่มต้นใหม่ขั้นสูง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “กลยุทธ์การเริ่มต้นใหม่ขั้นสูง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Erlang OTP: Distributed & Fault-Tolerant Systems Programming ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Erlang OTP: Distributed & Fault-Tolerant Systems Programming มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “กลยุทธ์การเริ่มต้นใหม่ขั้นสูง”

เจาะลึกกลยุทธ์การเริ่มต้นใหม่แบบ one_for_one, one_for_all และ rest_for_one พร้อมทำความเข้าใจผลกระทบต่อความทนทานต่อความขัดข้อง คุณปฏิบัติ Erlang OTP: Distributed & Fault-Tolerant Systems Programming ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Erlang OTP: Distributed & Fault-Tolerant Systems Programming หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Erlang OTP: Distributed & Fault-Tolerant Systems Programming บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “กลยุทธ์การเริ่มต้นใหม่ขั้นสูง” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Erlang OTP: Distributed & Fault-Tolerant Systems Programming นี้ได้ไหม

ได้ บทเรียน Erlang OTP: Distributed & Fault-Tolerant Systems Programming ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

โครงสร้างต้นไม้การควบคุมที่ซับซ้อน
การจัดการโพรเซสแบบไดนามิก
กลยุทธ์การเริ่มต้นใหม่ขั้นสูง
สะพานตัวควบคุมและลำดับชั้นกระบวนการแบบผสม

← กลับไปที่ Erlang OTP: Distributed & Fault-Tolerant Systems Programming