3

リアルタイムシステムの設計に使用される設計の概念と考慮事項をよりよく理解し、どのような種類のものを学びたいかを知るために、WPFアプリケーションで使用される架空の大量データ(オプション取引)を使用して独自のミニプロジェクトを作成したいと思いました。さまざまな手法とアプローチが使用されます。Tibcoのようなサードパーティのソリューションについては言及しないでください。これは学習目的です。私の意図は、WPFアプリケーションが5秒ごとにUIを更新することです

架空のマーケットデータサーバーを設計するとき、大量のパフォーマンスが基準であるとすると、いくつかの簡単なアイデアが思い浮かびます-マルチキャストUDP(これは低レベル/悪い方向ですか?)、キューを使用するメッセージングアーキテクチャ(MSMQなど)クライアントアプリがリモートサービスホストであるRabbitMQは、たとえばWCFTCPバインディングまたはWebサービスを介して要求を開始します。

私が持っていた1つの考えは、クライアントが独自のローカルキューを維持し、価格設定サーバーがメッセージングソリューションを使用してブロードキャストするトピックをサブスクライブすることでしたか?または、サーバーがすべてのクライアントにデータを均等にブロードキャストし、データをローカルでフィルタリングおよび照合するためにクライアントに任せるのではないでしょうか。人々の経験では、各アプローチの長所と短所は何ですか?私がここで見逃した他のアプローチはありますか?クライアントがデータをプルするのか、それともサーバーがデータをプッシュするのか、ということになると思います。

もう1つの質問は、これらのメッセージのワイヤ形式はどうなるでしょうか。私は主に、リポジトリ層、ドメインモデル(検証とワークフローロジックのメソッドを含む)、および単純なサービス層に分けられた、豊富なビジネスオブジェクトクラスの操作に慣れています。このアプローチを引き続き活用してパフォーマンス目標を維持できますか、それともより軽量のデータペイロード形式を作成する必要がありますか?

4

1 に答える 1

2

ネットワークレベルの最適化に進む前に、上位層からそのようなシステムの設計を開始します。

RabbitMQは、メッセージをルーティングするためのさまざまなタイプの交換を提供します。すべてのメッセージをすべてのクライアントにブロードキャストするアプローチ(ファンアウト交換)は、RabbitMQサーバー側ではわずかに高速ですが、これは少量のメッセージに対してのみ効率的に機能し、クライアントが高速リンク(ローカルギガビットイーサネットなど)を介して接続されている場合に限ります。代わりに、直接または局所的な交換を使用すると、ネットワーク遅延を大幅に減らすことができます。交換タイプの詳細については、RabbitMQWebサイトを参照してください。

最後の質問はワイヤーフォーマットについてです。理論的には、RabbitMQは任意の文字列(またはバイナリ)ペイロードを許可するため、より多くの情報をより少ないバイトに圧縮しようとする問題です。私の経験では、メッセージがネットワークパケットMTUを介していない限り、圧縮や巧妙なエンコード方式の選択によるメリットはわずかです。

一般に、各最適化に費やしている時間と、予想されるROIを考えてください。IMOのいくつかの最適化は、他の最適化よりも便利です。私があなただったら、RabbitMQ構成パラメーターを注意深く調べます。たとえば、プロセスごとのメッセージキューを使用してrabbitMQサーバーをセットアップできるかどうかを確認します。

于 2012-08-16T20:39:59.043 に答える