7

Perl で多層アプリの設計に取り組んでおり、利用可能なさまざまな IPC メカニズムの長所と短所について疑問に思っています。通常は数十キロバイトですが、最大で数メガバイトの適度なサイズのデータ​​を処理しようとしています。負荷は非常に軽く、1 分間にせいぜい数百リクエストです。

私の主な関心事は、保守性とパフォーマンスです (この順序で)。複数のサーバーにスケールアップしたり、メイン プラットフォーム (RHEL) から移植したりする必要はないと思いますが、考慮すべきことだと思います。

次のオプションを考えることができます。

  • 一時ファイル - 速度とストレージ要件の点でおそらく最悪のオプションです。
  • UNIX ドメイン ソケット - 移植性がなく、スケーラブルでない
  • インターネット ソケット - ポータブル、スケーラブル
  • パイプ - ポータブル、スケーラブルではない (?)

スケーラビリティと移植性は私の主な関心事ではないことを考えると、もっと学ぶ必要があります。最良の選択は何ですか?その理由は? 追加情報が必要な場合はコメントしてください。

編集: ysth の質問 に応じて、より詳細な情報を提供しようとします(警告、テキストの壁が続きます)。

  • リーダー/ライターは 1 対 1 の関係にあるのか、それとももっと複雑な関係にあるのか?
  • 読者が不在または多忙な場合、ライターに何をしてもらいたいですか?
  • およびその逆？
  • 希望する使用法について他にどのような情報がありますか?

現時点では、3 層のアプローチを検討していますが、各層にいくつのプロセスを含めるかはわかりません。左側に向けてプロセスを増やし、右側に向けてプロセスを減らす必要があると思いますが、全体的に同じ数にする必要があるかもしれません。

.--------. ----------。.--------.
 | | リクエスト | -----> | ビジネス | -----> | データ | データ
 | | マネージャー | <----- | ロジック | <----- | レイヤー |
 `---------' `----------' `---------'

これらの名前はまだ一般的なものであり、おそらくこれらの形式での実装にはなりません。

要求マネージャーは、Web 要求や CLI (応答時間が重要な場合) や電子メール (応答時間がそれほど重要でない場合) など、さまざまなインターフェースからの要求をリッスンする役割を果たします。ロギングを実行し、リクエストへのレスポンスを管理します（リクエストのタイプに適した形式でレンダリングされます）。

リクエストに関するデータをビジネス ロジックに送信します。ビジネス ロジックは、ビジネス ルールに応じてロギング、承認などを実行します。

次に、ビジネス ロジック (必要な場合) がデータ レイヤーからデータを要求します。データ レイヤーは、(ほとんどの場合) 内部 MySQL データベースまたはチームの制御外にある他のデータ ソース (たとえば、組織のプライマリ LDAP サーバー、または私たちのDB2 従業員情報データベースなど)。これはほとんどの場合、ビジネス ロジックでより簡単に処理できるようにデータを統一された方法でフォーマットする単純なラッパーです。

その後、情報は提示のために要求マネージャーに戻されます。

データが右に流れているときにリーダーがビジーである場合、インタラクティブなリクエストに対して、適切な時間だけ待機し、その時間内にアクセスできない場合はタイムアウト エラーを返します (例: 「後でもう一度やり直してください」)。非対話的な要求 (電子メールなど) の場合、ポーリング システムは単純に終了し、次の呼び出しで再試行できます (おそらく 1 ～ 3 分に 1 回)。

データが逆方向に流れている場合、待機状況は発生しません。左に戻ろうとしたときにプロセスの 1 つが停止した場合、実際にできることは、ログを記録して終了することだけです。

とにかく、それはかなり冗長でした。私はまだ設計の初期段階にあるので、おそらくまだ混乱したアイデアがいくつか残っています。私が言及したことのいくつかは、おそらく、どの IPC システムを使用するかという問題に接するものです。私は設計に関する他の提案を受け入れていますが、質問の範囲を限定しようとしていました (たとえば、IPC にとってははるかに簡単な 2 つの層に折りたたむことを検討する必要があるかもしれません)。あなたの考えは何ですか？

4

6 に答える 6

6

現時点で正確な要件が不明な場合は、 IPC 実装 (一時ファイル、TCP/IP など) がサポートする必要がある、コーディングできる単純なインターフェイスを考えてみてください。次に、特定の IPC フレーバーを選択し (私なら、デバッグが最も簡単で簡単なものから始めます。おそらく一時ファイルです)、それを使用してインターフェイスを実装します。それが遅すぎることが判明した場合は、TCP/IP などを使用してインターフェイスを実装します。実際にインターフェースを実装することは、基本的に既存のライブラリへの呼び出しを転送するだけなので、それほど多くの作業は必要ありません。

ポイントは、実行する高レベルのタスク (「プログラム A からプログラム B にデータを送信する」) があることです。これは、実行方法の詳細とは多少無関係です。インターフェースを確立してそれに対するコーディングを行うことにより、実装を変更する必要がある場合に、メイン プログラムを変更から切り離します。

インターフェイスを持つというアイデアを利用するために、重い Perl 言語メカニズムを使用する必要がないことに注意してください。たとえば、それぞれが同じメソッドのセットをエクスポートする 3 つの異なるパッケージ (一時ファイル、TCP/IP、Unix ドメイン ソケット用) を持つことができます。メイン プログラムで使用する実装を選択することは、どのモジュールを使用するかを選択することになりますuse。

于 2009-01-11T04:40:27.057 に答える
4

一時ファイルには、それ以外にも問題があります。インターネットソックスは本当に最良の選択だと思います。それらは十分に文書化されており、あなたが言うように、スケーラブルでポータブルです。それがコア要件ではない場合でも、ほぼ無料で入手できます。ソケットの取り扱いは非常に簡単ですが、ここでも大量のドキュメントがあります。データ共有メカニズムとプロトコルをライブラリに構築することができ、それをもう一度見る必要はありません。

于 2009-01-10T20:13:57.127 に答える
4

一時ファイル (および共有メモリ領域などの関連するもの) は、おそらく悪い賭けです。サーバーをあるマシンで実行し、クライアントを別のマシンで実行する場合は、アプリケーションを書き直す必要があります。他のオプションのいずれかを選択した場合、後でそれらを切り替える必要がある場合、少なくともセマンティクスは本質的に同じです。

ただし、私の唯一の本当のアドバイスは、これを自分で書かないことです。selectサーバー側では、ソケットで自分で行うのではなく、POE (または Coro など) を使用する必要があります。また、インターフェイスが RPC 風になる場合は、CPANの JSON-RPC-Common/などを使用してください。

最後に、IPC::PubSub があります。

于 2009-01-11T01:11:14.030 に答える
3

UNIX ドメイン ソケットは、Unix 間で移植可能です。パイプと同じくらいポータブルです。また、IP ソケットよりも効率的です。

とにかく、共有メモリなど、いくつかのオプションがありませんでした。そのリストにデータベースを追加する人もいますが、それはかなり重いソリューションだと思います。

メッセージキューも可能ですが、そのような大きなメッセージを処理するにはカーネルオプションを変更する必要があります. それ以外の場合、それらは多くのことに対して理想的なインターフェースを備えており、IMHO は非常に十分に活用されていません。

ただし、独自のソリューションを構築するよりも、既存のソリューションを使用する方がよいという点には概ね同意します。問題の詳細はわかりませんが、CPANのIPCセクションを確認することをお勧めします。

于 2009-01-11T01:33:27.653 に答える
2

「インタラクティブな」リクエストの場合 (応答を待っている間、接続を開いたままにする (非同期であるかどうかに関係なく): HTTP + JSON。JSON ::XSは非常に高速です。誰もがすべてのものを HTTP で話すことができ、ロード バランス、デバッグなどを簡単に行うことができます。 .

キューに入れられたリクエスト (「これをやってください、ありがとう!」) の場合: BeanstalkdおよびBeanstalk::Client。JSON を使用して、Beanstalk キュー内の要求をシリアル化します。

アプリケーションによっては、 Thriftも検討する価値があるかもしれません。

于 2009-02-05T10:03:13.480 に答える
2

それらのほとんどは特定のケースにより適しているため、非常に多くの異なるオプションがありますが、ケースを特定する情報を実際に提供していません。

リーダー/ライターは 1 対 1 の関係にあるのか、それとももっと複雑な関係にあるのか? 読者が不在または多忙な場合、ライターに何をしてもらいたいですか? およびその逆？希望する使用法について他にどのような情報がありますか?

于 2009-01-11T09:08:39.497 に答える