このテキストは、プロセスPIDを公開インターフェースとして使用する際の制限を説明し、発見可能なアドレスのための名前付きプロセスをソリューションとして紹介しています。ワーカーがクラッシュして再起動すると、新しいPIDが割り当てられ、古いPIDは無効になります。ローカルの無効なPIDにメッセージを送信しても、エラーは発生せず、プロセスも再起動しません。これを解決するために、クライアントはPIDを使用する代わりに、名前を依存し、メッセージ送信時にそれを解決できます。この記事では、プロセスに名前を付ける2つの方法、ローカル登録とグローバル登録を示しています。Process.register/2は、現在のBEAMノードでPIDを名前で登録し、Process.whereis/1経由でアクセスできます。メッセージは登録された名前に直接送信でき、ランタイムはそれを現在のPIDに解決します。ただし、Process.register/2はノードローカルであるため、異なるノード上の同じ名前は異なるプロセスを参照します。クラスタ全体のルックアップには、Erlangの:globalモジュールが使用されます。:global.register_name/2と:global.whereis_name/1は、接続されたノード間で名前の登録とルックアップを可能にします。3番目の例は、ワーカーが自身を登録し、公開名を返すことで、クライアントからPIDを隠す方法を示しています。クライアントはその後、PIDではなく名前にリクエストを送信します。重要なのは、プロセスに名前を付けることは、監視やライフサイクル管理を解決するものではなく、発見のみを解決することです。登録されたプロセスが終了すると、その登録は削除され、代替プロセスを開始して再登録する必要があります。通常、単一の名前は単一の所有者を参照するため、追加のルーティングメカニズムなしではワーカープールには適していません。フライト中の複数のリクエストを持つクライアントには、ユニークな参照を使用して返信を相関させることが推奨されます。最後に、:global登録は分散システムを促進しますが、ネットワークパーティションや同時主張などの課題を排除するものではありません。提示された中心的な考え方は、回復力のあるシステムを構築するために、一時的なPIDではなく、サービスロールのためにプロセス名を使用することです。