サーバーを含むNode.jsを使用したプロジェクトに取り組んでいます（簡単にするために、このサーバーを、特定のクライアントから他のクライアントにメッセージを転送する必要があるチャットサーバーと想像してください）。QoS の理由から、このサーバーは常に到達可能である必要があるため、クラスタリングを使用して、異なるサーバー (異なる物理マシン) 間で負荷のバランスを分散し、サーバーがダウンした場合に別のサーバーが要求を処理できるようにすることを考えました。 .
私の質問は、この種の分散アプローチは Node.js で可能ですか?
「クラスター」モジュールについては既に読みましたが、理解したところでは、同じマシン上のマルチプロセッサでのみスケーリングするようです。
はい、可能です。
これは NodeJS のプロパティではなく、アプリケーション用に設計したアーキテクチャによって、それが可能かどうかが決まります。
あなたの主な問題は、常にインスタンス間で状態を共有することです。つまり、4 つのチャット サーバー ABCD があり、4 つのサーバーに接続を分散する LoadBalancer L があるとします。その後、A がダウンすると、すべての A の接続を残りのインスタンスでは、チャットルームの状態が BC と D で同じであることをどのように確認しますか?
1 つの方法は、アプリケーション コードを完全にステートレスにし、すべてのデータを mongoDb や Redis などの分散メモリ データベースにプッシュすることです。データベース インスタンスの 1 つがダウンした場合に備えて、データベースを分散する必要があります。
最後の問題は LoadBalancer です。それがダウンすると、システム全体がダウンします。
つまり、長い話を短くするために。はい、できますが、潜在的な障害点がどこにあるかについて、いくつかの難しい決定を下す必要があります。単一障害点を回避したい場合は、複雑で費用のかかるセットアップが必要になります。
私の推奨事項は、独立したクラスターを活用して状態を共有することです。つまり、サーバーが互いに通信しない API クラスターを用意し、代わりに共通の Redis インスタンス/クラスターを共有し、共通の MongoDB クラスターを共有します。これにより、セッション、変数を共有でき、Redis の pub/sub 機能を活用して、API クラスター内でゴシップする必要がなくなります。
特にチャットの場合、クライアントとして Socket.IO で Redis を使用する場合、ロビーにブロードキャストするたびに、ロビー メンバーが複数のサーバーに存在するにもかかわらず、バックグラウンドで redis を使用してそのメッセージをそのロビーにブロードキャストします。さらに、これにより、任意のサーバーがソケットの再接続を管理できるため、別のレベルのフォールト トレランスが作成されます。Redis を介して状態を維持しながら、接続が切断された場合、socket.io は自動的に API クラスターに再接続します。