0Pricing
Elixir & Phoenix: Scalable Backend Development · 课时

监督者与应用结构

使用监督者监控并重启进程，设计具有韧性的应用，确保容错能力。

监督者与应用结构 是 CoddyKit 上的免费 Elixir & Phoenix: Scalable Backend Development 课时。 这是第 3 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Elixir & Phoenix: Scalable Backend Development 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Elixir & Phoenix: Scalable Backend Development 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Building Resilient Systems

In concurrent applications, things can go wrong. Processes might crash due to unexpected errors or external issues.

Fault tolerance is the ability of a system to continue operating even when components fail. Elixir embraces a "let it crash" philosophy, meaning instead of trying to prevent every single crash, it focuses on gracefully recovering from them.

Guardians of Processes

This is where Supervisors come in! A supervisor is a special kind of process designed to monitor other processes (its "children").

  • If a child process crashes, the supervisor automatically restarts it.
  • This ensures your application remains stable and available.
  • Supervisors form the backbone of fault-tolerant Elixir applications.

Your First Supervisor

Let's define a simple supervisor module. It uses the Supervisor behavior, similar to how GenServer uses the GenServer behavior.

The init/1 callback is where you define the children it will supervise and its restart strategy.

defmodule MySupervisor do
  use Supervisor

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  @impl true
  def init(_init_arg) do
    # No children yet, just the supervisor itself
    children = []
    Supervisor.init(children, strategy: :one_for_one)
  end
end

# --- Main execution part ---
# This simulates starting the supervisor and checking its status.
# In a real app, this would be part of an Application's start/2.
IO.puts("Attempting to start MySupervisor...")
{:ok, supervisor_pid} = MySupervisor.start_link([])
IO.puts("MySupervisor started with PID: #{inspect(supervisor_pid)}")

# Check if the supervisor process is alive
if Process.alive?(supervisor_pid) do
  IO.puts("Supervisor is alive!")
else
  IO.puts("Supervisor is NOT alive!")
end

Understanding Supervision Strategies

Supervisors have different strategies for handling child failures:

  • :one_for_one: Restarts only the child that crashed. This is the default and most common.
  • :one_for_all: If any child crashes, all other children are terminated and then all children are restarted.
  • :rest_for_one: If a child crashes, it and all children started *after* it are terminated and then restarted.

Choosing the right strategy depends on the dependencies between your processes.

Adding Supervised Children

To make a supervisor useful, it needs children! You define children using Supervisor.child_spec/2, which tells the supervisor how to start and manage a process.

Here, we define a simple MyWorker GenServer and add it as a child to our supervisor.

defmodule MyWorker do
  use GenServer

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  @impl true
  def init(:ok) do
    IO.puts("MyWorker started!")
    {:ok, %{}}
  end

  @impl true
  def handle_call(:crash, _from, state) do
    IO.puts("MyWorker is crashing!")
    exit(:bad_state) # Simulate a crash
    {:reply, :ok, state} # This line won't be reached
  end
end

defmodule MySupervisorWithWorker do
  use Supervisor

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  @impl true
  def init(_init_arg) do
    children = [
      # Define our worker as a child process
      Supervisor.child_spec(MyWorker, id: MyWorker)
    ]
    Supervisor.init(children, strategy: :one_for_one)
  end
end

# --- Main execution part ---
IO.puts("Starting supervisor with worker...")
{:ok, supervisor_pid} = MySupervisorWithWorker.start_link([])
IO.puts("Supervisor PID: #{inspect(supervisor_pid)}")

# Get the worker's PID
worker_pid = Process.whereis(MyWorker)
IO.puts("Initial MyWorker PID: #{inspect(worker_pid)}")

if Process.alive?(worker_pid) do
  IO.puts("Worker is alive and supervised.")
else
  IO.puts("Worker did not start correctly.")
end

Fault Tolerance in Action

Now, let's see the supervisor in action! We'll deliberately crash our MyWorker process, and the supervisor will automatically restart it.

Notice how the worker's Process ID (PID) changes, indicating a new process was spawned.

defmodule MyWorker do
  use GenServer

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  @impl true
  def init(:ok) do
    IO.puts("MyWorker started!")
    {:ok, %{}}
  end

  @impl true
  def handle_call(:crash, _from, state) do
    IO.puts("MyWorker is crashing!")
    exit(:bad_state) # Simulate a crash
    {:reply, :ok, state} # This line won't be reached
  end

  def crash_it do
    GenServer.call(__MODULE__, :crash)
  end
end

defmodule MySupervisorWithWorker do
  use Supervisor

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  @impl true
  def init(_init_arg) do
    children = [
      Supervisor.child_spec(MyWorker, id: MyWorker)
    ]
    Supervisor.init(children, strategy: :one_for_one)
  end
end

# --- Main execution part ---
IO.puts("Starting supervisor with worker...")
{:ok, _supervisor_pid} = MySupervisorWithWorker.start_link([])

worker_pid_before_crash = Process.whereis(MyWorker)
IO.puts("Worker PID before crash: #{inspect(worker_pid_before_crash)}")

# Crash the worker
IO.puts("Attempting to crash the worker...")
MyWorker.crash_it()
:timer.sleep(100) # Give supervisor a moment to restart

worker_pid_after_crash = Process.whereis(MyWorker)
IO.puts("Worker PID after crash: #{inspect(worker_pid_after_crash)}")

if worker_pid_before_crash != worker_pid_after_crash && Process.alive?(worker_pid_after_crash) do
  IO.puts("Worker was restarted by the supervisor! New PID detected.")
else
  IO.puts("Worker was NOT restarted, or PID remained the same (unexpected).")
end

Elixir Applications: The Top Level

While supervisors manage individual processes, an Elixir Application is the top-level unit of code and processes in an Elixir system.

It provides a structured way to:

  • Group related modules and processes.
  • Define how your system starts up and shuts down.
  • Manage configuration and dependencies.

The `Application` Behavior

Every Elixir application typically has a main application module that use Application.

The most important callback is start/2, which is invoked when your application starts. This is where you typically start your top-level supervisor, which then recursively starts all other processes in your system.

defmodule MyApp.Application do
  use Application

  # This is the entry point for your application.
  # It starts the top-level supervisor.
  @impl true
  def start(_type, _args) do
    children = [
      # In a real app, you'd start your main supervisor here.
      # For example: Supervisor.child_spec(MySupervisorWithWorker, id: MySupervisorWithWorker)
    ]

    # Start a supervisor that will supervise other processes/supervisors
    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

# --- Main execution part ---
# This part simulates how an application would be started.
# In a real Mix project, 'mix run --no-halt' would call MyApp.Application.start/2
IO.puts("Simulating application start...")
{:ok, pid} = MyApp.Application.start(:normal, [])
IO.puts("Application top-level supervisor started with PID: #{inspect(pid)}")

if Process.alive?(pid) do
  IO.puts("Application supervisor is active.")
else
  IO.puts("Application supervisor failed to start.")
end

Hierarchical Supervision Trees

For complex applications, you often don't have just one supervisor. You create a supervision tree, where supervisors can supervise other supervisors.

  • This allows you to organize your application into logical units.
  • Different parts of your system can have different restart strategies.
  • If a major component fails, its supervisor can restart it without affecting unrelated parts of the system.

Supervisor Check

Time for a quick check on your understanding of supervisor strategies!

Lesson Summary

Well done! You've learned how Elixir builds resilient applications:

  • Supervisors monitor processes and restart them upon failure.
  • Different supervision strategies (:one_for_one, :one_for_all, :rest_for_one) dictate how failures are handled.
  • Elixir Applications provide the top-level structure, starting supervisors and forming supervision trees.

These concepts are fundamental to building robust, fault-tolerant systems in Elixir.

常见问题解答

「监督者与应用结构」课时是免费的吗？

是的 — 「监督者与应用结构」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Elixir & Phoenix: Scalable Backend Development 课程的其余内容，请升级到 CoddyKit PRO。 Elixir & Phoenix: Scalable Backend Development 课程共包含 4 节课。

「监督者与应用结构」这节课中我会学到什么？

使用监督者监控并重启进程，设计具有韧性的应用，确保容错能力。 你通过在浏览器中直接运行的动手代码来练习 Elixir & Phoenix: Scalable Backend Development，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Elixir & Phoenix: Scalable Backend Development 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Elixir & Phoenix: Scalable Backend Development 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 3 节课，共 4 节。

「监督者与应用结构」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Elixir & Phoenix: Scalable Backend Development 课中编写并运行代码吗？

能。每节 Elixir & Phoenix: Scalable Backend Development 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. Elixir 进程与消息传递
  2. 实现 GenServer 行为
  3. 监督者与应用结构
  4. 使用 Task 与 Agent 进行并发工作
← 返回 Elixir & Phoenix: Scalable Backend Development