Verteiltes Elixir und Clustering
Verbinden Sie mehrere Elixir-Knoten zu einem Cluster, um verteilte Prozesskommunikation und die gemeinsame Nutzung von Ressourcen zu ermöglichen.
Verteiltes Elixir und Clustering ist eine kostenlose Elixir & Phoenix: Scalable Backend Development-Lektion auf CoddyKit. Dies ist Lektion 1 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 Elixir & Phoenix: Scalable Backend Development-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Elixir & Phoenix: Scalable Backend Development-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Why Distribute Elixir?
Welcome to distributed Elixir! This powerful feature allows your applications to run across multiple machines, forming a cluster of interconnected nodes.
Why is this important? It provides:
- Fault Tolerance: If one node fails, others can continue or take over.
- Scalability: Distribute work across many CPUs or servers.
- Concurrency: Manage many concurrent operations with isolated processes.
This capability is built upon the Erlang Virtual Machine (BEAM), which Elixir runs on.
What is an Elixir Node?
In Elixir, a 'node' is a running instance of the Erlang VM, typically hosting your Elixir application. When you start iex, you're starting a single Elixir node.
For distributed systems, nodes need to be able to find and communicate with each other. This is done by giving them unique names.
Naming Your Node
To enable communication, each node must have a name. You can start iex with a name using either --sname (short name) or --name (full name).
--sname: Used for nodes on the same host (e.g.,node1@localhost).--name: Used for nodes across different hosts (e.g.,node1@your_server_ip).
For this lesson, we'll use --sname as we'll simulate nodes on your local machine.
iex --sname node1 --setcookie mysecret
# In another terminal:
iex --sname node2 --setcookie mysecretSecure Node Connections: The Cookie
Before nodes can connect, they need to authenticate each other using a 'magic cookie'. This is a shared secret string.
If two nodes have different cookies, they will not be able to connect. This is a vital security feature to prevent unauthorized nodes from joining your cluster.
You set the cookie when starting iex using the --setcookie flag, as shown in the previous example.
Making Nodes Talk: Connect
Once you have two named iex sessions running with the same cookie, you can connect them using Node.connect/1. The argument is the full atom name of the target node.
Try running this in your node1 IEx session:
# In node1's IEx session:
Node.connect(:'node2@localhost')
# This attempts to connect to 'node2@localhost'.
# Make sure 'node2' is running with a matching cookie!
IO.puts("Connected to node2: #{Node.connected?(:'node2@localhost')}")Checking Node Status
After attempting a connection, you can verify which nodes are connected to your current node using Node.list/0. You can also get the name of your current node with Node.self/0.
Run this in any connected IEx session:
IO.puts("My node: #{inspect(Node.self())}")
IO.puts("Connected nodes: #{inspect(Node.list())}")
# If node1 and node2 are connected,
# Node.list() on node1 would show [:'node2@localhost']Messaging Across Nodes
Once nodes are connected, processes on different nodes can send messages to each other just like local processes. You just need the remote process's PID.
Let's see a process on node2 spawn, then send a message back to node1. Run the first part in node2, then the second in node1.
# In node2's IEx session:
pid_on_node2 = spawn(fn ->
send(self(), {:hello_from_node2, self()})
receive do
{:reply, msg} -> IO.puts("Node2 received reply: #{msg}")
end
end)
IO.puts("Node2 process ready: #{inspect(pid_on_node2)}")
# In node1's IEx session:
# (assuming node1 received the pid from node2)
receive do
{:hello_from_node2, pid_on_node2} ->
IO.puts("Received from Node2: #{inspect(pid_on_node2)}")
send(pid_on_node2, {:reply, "Thanks, Node2!"})
after 1000 ->
IO.puts("No message received from Node2 yet.")
endStarting Processes Remotely
You can also explicitly start a new process on a remote node using Node.spawn_link/2 (or Node.spawn/2). This is a fundamental way to distribute work across your cluster.
The first argument is the remote node's name, and the second is a fun (anonymous function) to execute on that node.
# In node1's IEx session:
remote_process_pid = Node.spawn_link(:'node2@localhost', fn ->
IO.puts("I am a process running on #{inspect(Node.self())}!")
Process.sleep(2000) # Simulate work
IO.puts("Process on Node2 finished.")
end)
IO.puts("Spawned process on Node2: #{inspect(remote_process_pid)}")Global Names for Global Access
For processes to be easily found by name across all connected nodes, you can use :global.register_name/2. This makes a process globally discoverable by its registered name, regardless of which node it's on.
Contrast this with Process.register/2, which only registers a name locally on a single node.
# In node2's IEx session:
:global.register_name(:my_global_worker, self())
IO.puts("Node2 registered :my_global_worker: #{inspect(self())}")
# In node1's IEx session:
# Give a moment for registration to propagate
Process.sleep(100)
worker_pid = :global.whereis_name(:my_global_worker)
IO.puts("Found global worker from Node1: #{inspect(worker_pid)}")
# Now you can send messages to it from Node1
if worker_pid do
send(worker_pid, "Hello from Node1 to global worker!")
endDistributed Concepts Check
Time for a quick check on what you've learned about connecting Elixir nodes!
Distributed Elixir Recap
Great job! In this lesson, you've learned the fundamentals of distributed Elixir:
- What Elixir nodes are and why they are named.
- The importance of the 'magic cookie' for secure connections.
- How to connect nodes using
Node.connect/1. - How to check connected nodes with
Node.list/0. - Sending messages and spawning processes across different nodes.
- Using
:global.register_name/2for cluster-wide process discovery.
These concepts are the building blocks for creating highly available and scalable Elixir applications!
Häufig gestellte Fragen
Ist die Lektion „Verteiltes Elixir und Clustering“ kostenlos?
Ja — der vollständige Text von „Verteiltes Elixir und Clustering“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Elixir & Phoenix: Scalable Backend Development-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Elixir & Phoenix: Scalable Backend Development-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Verteiltes Elixir und Clustering“?
Verbinden Sie mehrere Elixir-Knoten zu einem Cluster, um verteilte Prozesskommunikation und die gemeinsame Nutzung von Ressourcen zu ermöglichen. Du übst Elixir & Phoenix: Scalable Backend Development 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 Elixir & Phoenix: Scalable Backend Development zu starten?
Keine Vorkenntnisse erforderlich. Elixir & Phoenix: Scalable Backend Development 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 1 von 4.
Wie lange dauert die Lektion „Verteiltes Elixir und Clustering“?
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 Elixir & Phoenix: Scalable Backend Development-Lektion Code schreiben und ausführen?
Ja. Jede Elixir & Phoenix: Scalable Backend Development-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
- Verteiltes Elixir und Clustering
- Fortgeschrittene Supervisor-Strategien
- Dynamische Supervisoren und Registry
- GenStage- und Backpressure-Pipelines