موازنة الحمل والتحويل عند الفشل بين العُقد

In a cluster, spreading work across nodes prevents any one node from becoming a bottleneck and lets you scale by adding machines. Failover keeps the system available when a node dies.

A node sees its connected peers with nodes/0. This list is the pool you balance work over.

A simple strategy cycles through nodes in order, giving each an equal share of tasks.

spawn/4 can start a process on a chosen node, sending the work where you want it.

The pg module maintains named groups of processes spread across nodes. You can fetch group members and dispatch to them.

For low latency, prefer a worker on the local node when one exists, falling back to remote members otherwise.

Call net_kernel:monitor_nodes(true) to receive {nodedown, Node} messages when a peer disconnects, the trigger for failover.

On nodedown, redistribute that node's pending work to surviving nodes and remove it from your dispatch pool.

Stateless work is trivial to reassign. Stateful work needs its state replicated (e.g. via Mnesia) so a survivor can resume it. Design state placement up front.

When a node returns, do not dump all reconnection or rebalancing work at once. Stagger it to avoid overwhelming the cluster.

A resilient setup: register workers in a pg group, dispatch round-robin with local preference, monitor nodes, and reassign work on failure with state backed by replicated storage.

You learned distributed load balancing and failover.

• Dispatch work across nodes/0 with round-robin and local preference
• Use pg groups to track workers
• Monitor nodes and reassign work on nodedown
• Replicate state for stateful failover