並行フォークサーバーに関する設計の質問
私はクライアント/サーバーアプリケーションの設計の初期段階にあります。クライアントは、顧客の連絡先データ（名前、住所、電子メールアドレス、電話番号）のファイルを読み取り、これらのコンポーネントをサーバーに渡すバッチプログラムになります。サーバーは、それらを対応するmySQLテーブルに追加し（まだ存在しない場合）、IDを返します。コンポーネントごとに。パフォーマンスを向上させるために、サーバーは4つの「マネージャー」サーバーを生成し、それぞれが新しい行を検索して追加するタスクを実行し、4つのコンポーネントをIPCを介してそれらのマネージャーに渡します。それらが同時に働くことができること。
言い換えると
- バッチジョブからの接続をリッスンし、「スレーブ」プロセスをフォーク/実行するだけの1つの「マスターサーバー」、
- ソケットから読み取り、テーブルルックアップを実行し、場合によっては行を追加し、IDを書き戻す4つの「マネージャー」。
- 接続されたクライアントごとに1つの「スレーブ」プロセス。クライアントから新しい接続が到着したときにマスターによって生成されます。これはバッチジョブと対話します。顧客の連絡先レコードの受信、各マネージャーへのコンポーネントの送信、すべてのマネージャーの待機計算したIDで応答し、次のレコードを受信するためにループバックする前に、要約レコードをクライアントに送り返します。
（処理は私が説明したよりも少し複雑です-実際には8人のマネージャーがいて、最初の4人の結果を完全に収集する必要があります次の3人のマネージャーを呼び出す前に、最後のマネージャーを呼び出す前にすべてを完了する必要があります。ただし、これはいくつかの連続した段階を伴う単純なプロセスであり、各段階では、同時作業を実行し、すべてが完了するのを待ちます。）
これについてチームの他のメンバーと話し合ったときに、「マスターサーバーとスレーブサーバーがあるのはなぜですか？クライアントがこれらのマネージャープロセスと直接別々の接続を確立しないのはなぜですか？」と尋ねられました。
私は本当に良い異議を唱えていません。各クライアントcouldは基本的にスレーブロジックを直接実装し、マネージャーサーバーへの8つの同時接続を作成します。最善のアプローチではないと感じています。障害やエラーを確実に処理したり、サーバー全体に関する統計を蓄積したりするために、集中管理を行うことがどういうわけか重要かもしれません。しかし、私はこれまで、本格的で本番環境に適したクライアント/サーバーアプリを構築した経験はありません。
この種のアプリを作成した経験のある人の意見を聞いてみたいと思います。
PDATE 1： 1つの利点：クライアントプロセスが突然クラッシュまたはキャンセルされた場合、スレーブプロセスは存続し、クライアントが離れたことを検出し、ジョブの状態を完全に把握し、現在の作業単位を完了する（または取り消す）ことにより、データの整合性を確保します。それは失敗を秩序正しく終わらせることができます。
要するに、あなたの同僚への答えは「カプセル化」です。
9人目のマネージャーをスピンアップする必要があるときはどうしますか？または、クライアントごとにより多くのスレーブプロセスがありますか？または、既存のすべてのクライアントを強制的に更新して無効にするのに十分なだけ対話ロジックを調整する必要がありますか？それを行うために、すべてのクライアントを完全に制御できますか？
クライアントが行う処理needsのようには聞こえないので、そうすべきではありません。
また、理論的には、マスター/マネージャー/スレーブを制御できるため、クライアントよりも少しだけそのコードを信頼できます。クライアントを作成/公開している場合でも、セキュリティの観点から見たいと考えています。クライアントは一般に、サーバーコンポーネントよりも信頼性が低くなります。これは、ユーザーが制御するシステム以外のシステムに展開および存在するためです。また、ロジックがクライアント内にある場合、変更を加える能力を実際に損なう可能性のあるダウンレベルのクライアントバージョンをサポートする必要がある場合もあります。
あなたはクライアント/サーバー環境への正しい道を進んでいます。始めたデザインに固執し、クライアントに不適切なアクセスを提供しないでください。