3

やあ、

現在、amqキューから2つの値を取得し、それらに対して一連の数学的計算を実行するプログラムを開発しています。プログラムがサブスクライブし、コールバック(リスナー)を介してメッセージを受信するamqサーバーにトピックが作成されました。

これで、メッセージが到着するたびに、2つの値が取り出され、SynchronizedDescriptiveStatisticsオブジェクトに追加されます。値のリストに追加するたびに、一連の計算全体が最初からやり直されます(これは実際には要件の一部です)。

私が今直面している問題は、リスナーを使用しているため、計算の途中で1つ以上のメッセージが受信されることがあるということです。SynchronizedDescriptiveStatisticsは、スレッドに関連するすべての問題を自分で処理しますが、ロックが解除されたときなどに、待機中のすべての値を番号のリストに一度に追加します。私の問題は、1つの値を追加してから、その値に対してcalclsを実行し、次に2番目の値を実行することでした。

私が思いついた解決策は、プログラムでジョブキューを使用することです(amqキューではありません)。このようにして、計算が終了するたびに、プログラムはキュー内のさらなるジョブを探し、それに応じて続行します。

効率と速度も求めているので、Disruptorフレームワークはこの問題に適している可能性があり、スレッド化された状況に最適化されていると思いました。しかし、Disruptorをアプリケーションに実装するのに苦労する価値があるかどうかはわかりません。これは、通常の標準キューで十分な場合があるためです。

また、計算を実行する必要のあるデータはたくさんあり、それは今後も続き、単一の値を連続的に追加するたびに、計算全体をもう一度実行する必要があることもお伝えしておきます。したがって、効率性と膨大な量のデータを念頭に置いておくと、長期的には何が役立つと思いますか。

返信を待っています。。。

よろしく。

4

1 に答える 1

13

この質問に対する私たちの典型的な答えは、まずテストを行い、結果に基づいて決定を下すことです。

効率性について話していますが、パフォーマンスが基本的な要件であると具体的には述べていません。パフォーマンス要件を把握している場合は、キューを使用した単純なプロトタイプと Disruptor の基本的な実装をモックアップし、両方のパフォーマンスを測定できます。

一方が他方よりも大幅に優れている場合、それがあなたの答えです。ただし、実装するのにはるかに手間がかかる場合、特に必要な効率が得られない場合、または厳しいパフォーマンス要件がない場合は、そのソリューションが適切ではないことを示唆しています。

最初に測定し、結果に基づいて決定します。

于 2011-12-20T10:49:22.647 に答える